Being a senior software developer
Being a senior software developer is not just something you sit and wait 10 years to magically morph into. There’s work to do, and not just hard work. There are many articles around, so I’ll focus on my experience and the aspects I value most.
Tools are not only software based — you also need mental tools to deal with the daily challenges. When something serious is happening in production, a senior will have the cold blood to deal with the it, knowing that the stress will not send the clock behind. Another example is when you have resistance to changes in “your” code. But the moment the code is pushed to the repository, it’s not yours anymore — it’s company owned. Code that changes is natural and healthy code, so don’t get too attached to it.
You should try to put your emotions aside in conversations and decisions. You loved using React in the previous project but that is not an argument for the next similar decision. And just because Google uses some library, it does not mean you should. Justify options with facts and don’t let your personal preferences bias the discussion. Tools are not toys to play around.
Don’t be the guy who found the killer programming language. Your language sucks. This applies to any tool that promises to solve all purposes — there are no holy grails in software development. That’s like saying you found the perfect car or phone and they should stop producing the rest. Please stop saying Windows or PHP or AngularJS or Android are bad. Don’t be hater of X unless you want X lovers to be hater of you — people do get personal on these things. Most technologies have a purpose and play a role somewhere but none everywhere. Few are inherently bad. That said, analyze the problem and only then select the adequate tool, which might not be the best tool around (i.e. best != adequate). Don’t forget that “if all you have is a hammer, everything looks like a nail”.
Don’t bully others because they don’t master the vi editor or the shell commands. It may be good enough for you but others may prefer IDEs and other visual tools. The best tool for you is not the best tool for others. Again, best differs from adequate — adequate is what works for you. At the end of the day, what matters is what you deliver. In previous teams I worked, some people used an IDE for everything and others used Sublime and the console. The team worked fine except when bullies came and flaunted that “a real programmer does not use an IDE”.
It’s common to hear “That’s easy; I can do it in 2 hours!”, but try to respect the problem’s difficulty. A junior feels the need to show off and to be accepted, but that’s just impulsiveness. A senior refrains from making quick promises and uses the adequate techniques to make better estimations. The general idea is to do a bottom-up approach (split into smaller tasks, estimate, sum it up). We love transparency from the management regarding project/company issues, so why not be transparent as well? A great developer will keep the managers updated, managing expectations, so they can make informed decisions and eventual trade-offs.
Learning is not over after university. Keeping up with the industry is a must for software developers. Ask a doctor or a lawyer. Since our profession is more dynamic, we should be learning nonstop. Half of people think experience is everything and half are academics full of theories. None is right. Blend practice (e.g. your job, pet projects) with theory (e.g. talks, reading, courses).
There’s no excuse for not grasping some technology, considering all the high quality free (Youtube has tons of material) and low-priced courses available online (for around 12€ each, Udemy has high quality courses, divided in small videos). You don’t need to spend family time if you take 15 daily minutes at work. With that, I complete 3/4 courses a year. Even if you’re not actively using something at work, it might be useful (I took a Vue JS course that updated me on frontend concepts). Be good in one or two things and be aware of the rest.
Why not use comute time for some reading? Search for “software developer must read books”, choose one and send it to your e-reader. I’m not a fan of it, but there are also podcasts on software development that you can keep up while going for a run. Start a blog and write about what have you learned, passing the knowledge to others. If you have no ideas for blog posts, why don’t you do reviews/summaries of those books? Personally, when writing in my blog, I feel forced to think and research before (to avoid errors), consolidating knowledge by creating a mental model of the topic.
Regarding talks, just go to meetup.com and start joining your favorite groups in town. Investing two hours a month (I go to one talk per month in average; one is “much bigger” than zero) to hear about some technology and network with some people with different backgrounds is undoubtedly rewarding (not only in career development). You won’t become a pro in any of the topics, but you’ll perceive the trends and get to know the problems and solutions people are discussing. Be good in one or two things and be aware of the rest.
You were not hired to be a geek. You are not paid to show off your tech skills. You serve customers and users. Accept it. You likely serve some kind of business. It’s easy to forget that, specially if you’re in a product company surrounded by software engineers who love to try new libraries, databases and boast their shell expertise. That’s nice, but prefix your actions by weighing the value those could bring to the user, directly or indirectly.
Dealing with people is a necessity. There’s the myth that we’re computer-only people but that’s just plain stupid. We may deal with clients and customers, we respond to managers, we belong to a team, we integrate with others’ software and onboard new hires, and the software you build will be ultimately be used by humans. A senior is empathetic and knows how to communicate with non-technical people, starting by introducing the relation with the business, without technicalities, focusing on the “whats” rather than the “hows”.
I hear a lot of bashing the user (“How can’t he see the button!? Is he dumb?!”). But if the user can’t accomplish A or B, that’s your fault! UX plays a central point here and that’s why I think every developer should have at least a crash course on it. The same argument applies to your code. Your code also has users — the other developers. They’ll use it as an API, as a library or directly. If other developers don’t understand how to use/change your code, it’s your fault. Your code should be expressive and concise enough to speak by itself. If you need to add a lot of comments to it, that might be a symptom of bad design.
Some developers undervalue the preparation tasks before coding. They just want to show off their coding skills and bypass the research, specification and design that should happen before. Besides the obvious upside in sharing and collaboration, these tasks allow you to iterate in our head and become acquainted and confident with the goal and its implementation. I love coding and it’s a pain to detail tasks, but that forces me think before coding. The coding just feels more natural.
If you’re a frontend developer, it’s vital to master paper prototyping. In terms of software design or project architecture, it’s important to use some drawing tool (like Google Drawings or Visio) to communicate complex concepts and improve the company’s knowledge base. In GitHub issues that impact some GUI, paste some screenshots. If you’re doing some data analysis to be shared, use tables, charts and other visual artefacts.
Many seniors believe it’s not their job to coach. But who should do it then? A senior knows how to deal with juniors, assigning didactic tasks, “suffering” with them instead of just dispatching work (e.g. “go to the Jira board and grab something”). A senior is not patronizing and does not make juniors feel stupid. In few words, a senior is empathetic and can easily be in the juniors’ shoes.
A senior mentors and inspire others but is also an enabler, creating the conditions for juniors to work better. One interesting technique to ease on-boarding I saw working, is to assign juniors easy but global tasks like fixing casing, indentation, cleanups and simplifications. These tasks allowed them to take care of the codebase as their own, creating an emotional connection. They’re also an opportunity to familiarize with the team practices.
Be careful not to “teach before time” and don’t force your help as it can be annoying when you just want to boast your vast knowledge. Let the juniors try and make mistakes and only then offer your help. Maybe then you can give some contextual small teachings.
I don’t see a problem with a junior teaching a senior but a lot of seniors do: they get a bit defensive and afraid to look ignorant. Learn to say “I didn’t know that”, “that’s interesting”, “we could use that”. It’s important to value others’ knowledge thus gaining their trust and respect. Software development is so diverse that everybody is senior at something.
I don’t want to go on a motivational speech here, but the way you face problems makes a huge difference. Two different persons looking at the same thing, can see two very different things. Where one sees a problem, the other sees an opportunity. If you’re feeling some “pain” at work, could you explore what to learn from it? Just some quick examples:
- Don’t like your manager style? Learn what not to do when it’s your turn.
- Don’t like the technology choices? Use the opportunity to form an opinion about them; create a proof of concept proposing something better.
- Don’t like the company bureaucracy? Propose a simplified process; do something disruptive.
- Don’t like a lot of meetings? Volunteer to be a moderator and promote better communication.
- Hate repetitive tasks? Propose new workflows and/or automate processes.
Many problems seem hard at first sight, like a fuzzy big ball of requirements. Our first human response is to curse the product, complain of the management, blame the technologies, etc. But our ideal response should be persistence — we should tackle the problem by different sides, namely by detailing it with diagrams, talking with the proper people, investigating, and making code experiments. I forgot how many times I was overwhelmed with a problem. I had to “face the bull by the horns” and keep fighting/iterating. In the end, I recall thinking: “this was not that hard”; “how could have I thought that before?!”.
On the other hand, your attitude can greatly influence the ones around (specially juniors), for better or for worse. Behavior generates behavior. Do you want to drag the team to the pit? Do you know that guy in the office always complaining? Perhaps you’ve been there and you didn’t realize. Don’t play the victim game or complain about things you can’t change. Perhaps you’re the one who needs to change. In our line of work, there are lots of opportunities (although there are no perfect jobs). Change what you can, accept the rest, or turn the page.
Your daily energy is finite, so choose your battles wisely. Be an influencer. Perhaps you can’t change the whole company or the whole department. But what about one or two colleagues? Maybe later, the team.
The bottom line is: what you take from each experience — good or bad — is up to you.
I think it’s obvious that a senior should not just be just an “executor” and instead, should question the management, the product and the technical decisions. However, sometimes questioning everything is not practical. There’s the ideal world and the real world; a senior developer should be able to balance them accordingly. For example, ideally all team members should attend all meetings and share all decisions. In practice, sometimes, two members are enough to move forward an initiative to be shared and discussed later. Ideally, Swift should be used; in practice, we can’t for legacy reasons. I could go on and on, but the lesson is: the world is not perfect but it must move forward.
As a final remark, I would recommend to embrace uncertainty. It widens your mind to deal with different situations. Assertiveness is a great quality, specially if you have to face the client or other stakeholders. But when you breath certainties, you start to believe you know it all. You stop hearing, asking questions, pursuing improvement, when you feel certain you mastered a subject. Dunning-Kruger effect explains it better. Admitting ignorance can be haunting though. Eventually, it can lead to the impostor syndrome. Still, I prefer to deal with that, rather than to be that obnoxious guy so sure about everything that doesn’t realize he might be that guy.
“Uncertainty Is an Uncomfortable Position. But Certainty Is an Absurd One.” — Voltaire
Sometimes you just need to “feel dumb” to welcome new paradigms, languages, and techniques. By embracing uncertainty, a senior also understands that there are no universal solutions, given the uncertainty of the world. Seniors also learn to respect users and other stakeholders, specifically dealing with more junior developers and understanding their perspectives. A senior will look into him/herself and learn what can be changed.
Most of the presented advices are easier said than done. However, my hope is that after reading them, something can be left in your subconscious and, who knows, trigger an introspection and shape some of your future actions.
Do you have something to add? Feel free to give your opinion in the comments section.