CODEX
Being a senior software developer
Being a senior software developer is not just something you wait ten years to morph into magically. There’s work to do and not just hard work. Many articles are around, so I’ll focus on my experience and the aspects I value most.
Emotion management
Tools are not only software-based — you also need mental tools to deal with daily challenges. An example is when you resist 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, so don’t get too attached.
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 libraries 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 with.
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, PHP, AngularJS, or Android are bad. Don’t be a hater of X unless you want X lovers to be a hater of you — people do get personal on these things. Most technologies have a purpose and play a role somewhere, but not everywhere. Few are inherently bad. That said, analyze the problem and select the adequate tool, which might not be the best 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 haven’t mastered the vi editor or the shell commands. It may be good enough for you, but others prefer IDEs and 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. What matters is what you deliver. In previous teams I worked with, 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”.
Pair programming is an excellent technique to do code reviews on the fly, quickly spread know-how, ramp up new hires, facilitate decisions, etc. There’s a whole set of tips that I recommend having in mind when pair programming.
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 needs to show off and be accepted, but that’s just impulsiveness. A senior refrains from making quick promises and uses adequate techniques for better estimations. The general idea is to do a bottom-up approach (split into smaller tasks, estimate, and 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 that they can make informed decisions and eventual trade-offs.
Continuous learning
Learning is still ongoing 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 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 into 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 front-end concepts). Be good at one or two things and be aware of the rest.
Why not use the commute time for some reading? Search for “software developer must-read books” (check my list), 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 you have learned, passing the knowledge to others. If you have no ideas for blog posts, why don’t you do reviews/summaries of those books? 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, go to meetup.com and start joining your favorite groups in town. Investing two hours a month (I go to one talk per month on average; one is “much bigger” than zero) to hear about some technology and network with people with different backgrounds is undoubtedly rewarding (not only in career development). You won’t become a pro in any topics, but you’ll perceive the trends and learn the problems and solutions people discuss. Be good at one or two things and be aware of the rest.
Communication
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 business. It’s easy to forget that, especially if you’re in a product company surrounded by software engineers who love to try new libraries and 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 ultimately be used by humans. A senior is empathetic and knows how to communicate with non-technical people, starting by introducing the relationship with the business without technicalities, focusing on the “what” rather than the “how”.
I hear much bashing about 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, so 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, like 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 many comments, that might be a symptom of bad design.
Some developers undervalue the preparation tasks before coding. They want to show off their coding skills and bypass the research, specification, and design that should have happened before. Besides the obvious upside in sharing and collaboration, these tasks allow you to iterate in your 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 to think before coding. The coding feels more natural.
If you’re a front-end developer, it’s vital to master paper prototyping. Regarding software design or project architecture, using some drawing tool (like Google Drawings or Visio) to communicate complex concepts and improve the company’s knowledge base is important. 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 artifacts.
Coaching
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 and “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 a few words, a senior is empathetic and can easily be in the junior’s shoes.
Senior mentors inspire others but are also enablers, creating the conditions for juniors to work better. One interesting technique to ease onboarding 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 themselves with the team practices.
Be careful not to “teach before time”, and don’t force your help; it can be annoying when you want to show off your vast knowledge. Let the juniors try to make mistakes, and only 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 many seniors do: they get a bit defensive and afraid to look ignorant. Learn to say “I didn’t know that”, “that’s interesting”, and “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.
Attitude
I don’t want to go on a motivational speech here, but how 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 “pain” at work, could you explore what to learn? Here are just some quick examples:
- Don’t like your manager style? Learn what not to do when it’s your turn.
- Don’t like the choices of technologies? 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.
- Do you hate repetitive tasks? Propose new workflows and/or automate processes.
Many problems seem hard at first sight, like fuzzy balls of requirements. Our first human response is to curse the product, complain about the management, blame the technologies, etc. But our ideal response should be persistence — we should tackle the problem from different sides by detailing it with diagrams, talking with the proper people, investigating, and doing code experiments. I forgot how many times I was overwhelmed by a problem. I had to “face the bull by the horns” and keep fighting/iterating. I recall thinking: “This was not that hard”; “How could I have thought that before?!”.
On the other hand, your attitude can greatly influence the ones around you (especially juniors) for better or worse. Behavior generates behavior. Do you want to drag the team to the pit? Do you know that guy in the office who always complains? 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. Our line of work has many 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.
Final words
I think it’s obvious that a senior should not just be 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 do it. I could go on and on, but the lesson is that the world is not perfect, but it must move forward.
As a final remark, I recommend embracing uncertainty. It widens your mind to deal with different situations. Assertiveness is an excellent quality, especially if facing the client or other stakeholders. But when you breathe certainties, you believe you know it all. You stop hearing, asking questions, and pursuing improvement when you have mastered a subject. The Dunning-Kruger effect explains it better. Admitting ignorance can be haunting, though. Eventually, it can lead to impostor syndrome. Still, I prefer to deal with that rather than to be that obnoxious guy so sure about everything that he doesn’t realize he might be that guy.
Uncertainty Is an Uncomfortable Position. But Certainty Is an Absurd One. — Voltaire
Sometimes, you must “feel dumb” to welcome new paradigms, languages, and techniques. By embracing uncertainty, a senior also understands that there are no universal solutions, given the world's uncertainty. 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 advice is easier said than done. However, after reading them, something can be left in your subconscious and, who knows, trigger introspection and shape some of your future actions. Do you have something to add? Feel free to give your opinion in the comments section.