4 things I learned from becoming a lead developer in my first year as a self-taught professional programmer
This essay goes out to all those who decided to jump on the developer bandwagon a little later than most of their peers. Maybe you’ve just created your first `index.html` file and are interested in what professional software development looks like. Maybe you’ve just landed your first job in web development. Maybe you even have a few years of experience and are now considering moving to a more senior role in your company. Here I humbly share some things I learned while becoming a lead developer in my first year as a self-taught programmer without any formal education in computer science 🐣
Entering the world of professional software development without an education in a relevant field is not exactly easy. I had my first experience with the development of an enterprise web application in my role as a working student in a huge law firm I was working for while studying for my degree in social anthropology. At some point I was asked to supervise the results of a new onboarding-system which the internal ‘IT’ team was developing for new clients. In exchange with a QA manager I tested the new application for months before it would become ready to be released to the public.
Seeing what was possible in the scope of a ‘modern’ (🤦🏽♂️) web application made me realise how much I would enjoy being able to make things move on the screen on my own. So I started searching for online courses on web development, diving into Javascript tutorials, figuring out how to make buttons move with jQuery and how to create a simple blog with Ruby (on Rails) and my SPA-framework of choice, AngularJs.
I got lucky and had the chance to join a local startup as a working student. The company was just looking to hire new frontend developers for the further development of their web applications. They gave me the chance to prove myself and so I did. Even without much work experience and extensive technical skills I was promptly hired as a full-time frontend developer. Eventually more and more developers and interns joined the team and had to be organised across our three core-products. The CTO, who at this point had become a good friend of mine, asked me if I would feel comfortable to lead the team for one of these products as a disciplinary squad lead and I (sort of) confidently took to the offer.
At this point I had a good idea of how our frontend applications worked but I was far from labelling myself an ‘experienced’ web developer. I talked to the CTO and he was convinced that being able to talk to people and understanding what motivates them was equally as important as knowing the inner workings of a product from a business and from a technical side.
After almost two years in this role I put together a list of things I learned in my role as a team lead while continuously aiming to improve my skills as a professional web developer. I hope it helps or motivates you to make a decision on where to go next!
#1 Software development is not all about writing eloquent code
Since joining the team I had added more than 150.000 lines of code to the products I was asked to develop and maintain. That’s at least what Github told me 🤷🏼♀️
However, between coding sessions I learned that being a good interface to stakeholders and users was equally as important. Without understanding the need behind a feature I wouldn’t be able to fully explain a development task to my colleagues. Stakeholders aren’t always perfect and it hardly ever happens that they contact you with a fully prepared user-story. So it is important that you as their interface are able to understand whatever they need from your product and translate it to an actionable item on your developers’ todo lists.
Unless your company employs dedicated designers or product managers, you might have to enable developers to conceptualise features on a non-technical level. In either way you and your developers will have to find a way to define object models and chose the fitting architecture for your system, but unless you can create a functional and approachable interface, your users will not profit from any of it.
Reading up on UI/UX topics and learning to see your product with the eyes of various user types enables you as a lead to prepare feature requests in a way that will generate business value in the end.
#2 You don’t have to be the best programmer in the team to be a good lead
When I joined the company I had been building web applications in private for less than a year. I was definitely at a junior level and, in addition, I was the only member of the team who didn’t graduate in computer science. In fact, I had completed a Bachelor’s degree in ‘social anthropology’ a few years earlier and was just going to complete my thesis for my Master’s degree in the same field. Not exactly a technical education in the traditional sense. My team consisted of a full-time intern who was just completing his Master’s degree in computer science and a young professional who had already been developing software as a passion for many years. Appointing me as a squad lead was a risky decision, but it turned out well since I brought some skills to the position which turned out to help us be very productive as a team 👨👨👦
Being able to put yourself in someone’s shoes is an essential talent if you’re required to translate between stakeholders and developers. This skill combined with some sense of empathy will let you lead a team in a very productive manner. Identifying a colleague’s strengths and understanding their weaknesses allows you to complement them in an efficient way. For example, if you sense that someone feels uncomfortable with the amount of responsibility they were given in a certain project, you can mentor them and let them grow to become more independent. Understanding what excites and motivates your colleagues and users is equally as important as understanding what frustrates them.
Being a lead doesn’t mean that nobody can teach you anything anymore…
I remember talking to a newly hired developer who was asking me for some advice on how to solve a problem in the backend. At that point in time I was only working on the frontends of our applications and wasn’t sure how to help out. Still she was convinced that since I was a lead I would certainly know a better way than her to solve the issue. Instead of riding that wave I admitted that I was probably less skilled than her, but that I’d love to help her figure out the issue while explaining to me what exactly she was trying to do. In the end we figured it out together and both learned something on the way.
#3 Startups are an amazing place to grow
If you’re just starting out with your career in software development, then startups are an amazing place to get started. Depending on the product categories you might join a small team of developers with a very broad skillset, driven from a passion of solving complex problems and creating fantastic products.
In small interconnected teams, company culture can tend to be equally as important as qualification. If you’re dedicated to grow and join the efforts of growing the company, you will be embraced by the talent surrounding you. You will learn a lot by talking to people from various departments, exchanging ideas for free-time projects and participating in external events with your colleagues. People enjoy sharing their knowledge. It might just be your responsibility to create a space in which they can share it with you. What is important in that context is that you don’t stop to seek challenges. Don’t stop challenging yourself and others.
While challenging yourself you can set yourself goals like developing small projects in your free-time, using a new framework or that programming language your colleague told you about while having a beer on the terrace.
While challenging others you can try to do some sparring with your more ‘opinionated’ colleagues and friends. Tell them that only ‘bad programmers comment their code because they forget what it does’. A discussion about ‘tabs vs. spaces’ is also a nice treat for your lunch break.
#4 Humbleness always pays off
In many career paths people tend to hide behind a mask of ‘fake it till you make it’. This can definitely be useful in a situation in which you are trying to sell an idea, but you need to always be aware of where your limits lie. A good friend of me likes to say: ‘real recognise real’. If you’re exploiting your position to make unqualified decisions, the people with real qualification will soon start to notice. On the other hand, if you stay ‘real’ and approach conflicts with honesty and confidence in the knowledge you have, you will most definitely be rewarded by your skilled peers. Admitting that you do not understand something is a good thing and will most likely lead you towards a solution faster than hiding behind a curtain of technical terms and superficial knowledge.
If you stay real with yourself and use honesty and transparency as a leadership tool, your peers will respect you for the positive impact you have on your team while allowing you to grow into the position that was given to you.
This essay was inspired by a conversation I had with a good friend who was at that time considering where to move next in his career as a developer. The beauty about the art of professional software development is that it allows you to go in various directions; from becoming an expert on the underlying technology and excel as a programmer to going into leadership and supervision of the surrounding processes of creating amazing products for the world to profit from.
The sky is the limit!
