This article was originally published in my blog www.yourdevopsguy.com.
What is the difference between a junior and a senior developer?
When I first started coding I also felt lost and overwhelmed. I thought I needed to focus only on my coding skills to get promoted to senior. Over time, I realized the difference between a junior and a senior developer.
Senior software engineers design solutions to complex, open-ended problems, with no guidance. They gather requirements, design solutions, tasks, code, deploy and maintain the system. They care about the system's performance, security, testing, extensibility, scaling, instrumentation, and maintainability.
This is something I later learned as part of a training session at Amazon on how to move to the next level. They expect seniors to figure out how to solve problems on their own, while juniors need guidance. This does not mean they know everything. This includes knowing when and how to ask questions, which takes experience. Senior engineers take tasks that no one else wants to do and that cannot be solved with a simple Google search.
Do not equate years of experience with wisdom. There are people with 10 years of experience and people who have experienced the same year ten times. I recommend never getting too comfortable with what you are doing to keep growing.
This is a list of tips I wrote during my first year as a software developer. They come mostly from making mistakes and observing team leaders and principal engineers.
15 things I wish I had known sooner
How to work more efficiently
1. For every task you work on have a clear definition of done
This helps with planning, keeps you focused on what you need to do, and makes it easier to document your work. Even for open-ended tasks, there should be a clear goal: for instance, a decision to use technology A or B.
2. Define the scope
Make sure the scope of the task is well defined too. Do not waste time on things out of your or your team's scope.
3. Time estimates are hard
I have usually overlooked at the time I needed to:
Design and choose a solution.
Change or add new tests.
Get my colleagues to approve my pull request.
4. Mindset
Have a look at the Amazon Leadership principles. They provide a good mindset for your transition to a senior level, especially:
Ownership
Bias for action
Dive deep
Earn trust
Disagree and commit
Sometimes principles may contradict, so take make a decision based on your situation. A senior developer does not just write code but is a leader that takes impactful decisions.
How to optimize your work
5. Automate
Automate as much as you can. It is obvious that you gain a lot of time in the medium and long term, but this has to do with the number of iterations, not time. You need to have a rule to decide when to automate a task. Personally, if I find myself doing twice something that I can automate, it is time to write a script.
6. Work incrementally
Do not write 1000 lines of code before you start testing it. Work and verify your changes incrementally. Check if the code can compile, or you forgot to import a library (good IDEs with this). Doing things right from the start is easier than redoing sloppy work. From the outset, write readable code, unit tests, do small refactors, etc.
7. Premature optimization is the root of all evil
Avoid premature optimization. This is not the same as not using the most appropriate data structures and algorithms from the beginning. Your focus should be to write code that works and later make it efficient. Write code, use a profiler to find the real bottlenecks and focus on optimizing them.
8. Get a rubber duck
Before you ask for help, get a rubber duck. It can be a virtual one. Before you ask for help, explain the problem to your rubber duck and how you are trying to solve it. Go through your code line-by-line. Chances are you will find the solution. If not, you will be able to better articulate your question to your colleague.
9. Revise your assumptions
When things go wrong, check your assumptions. I wasted long hours debugging issues that came from:
reading the wrong configuration file
using outdated information from an internal wiki page
problems with someone else's code
copy-paste related errors
Logging and quick chats can speed things up.
10. Read the documentation
I have also avoided reading the documentation out of pure laziness. If your team's documentation is unclear or lacks information, improve it.
11. Beware of comments
"Code never lies, comments sometimes do." — Ron Jeffries
The best comment is the one you don't have to write. Comments, like code, can rot and be misleading. If you are going to write a comment, make sure it is the best comment you can write
Do not state the obvious
Be brief and precise
Check your grammar and punctuation
Remove comments that produce noise
12. Learn to communicate
Coding has more human interaction that people think. You need to interact with people to define tasks and ask questions. Also, when you read and write documentation and comments.
Consider clear and effective communication as part of your job requirements.
How to approach complex, open-ended tasks
13. Ask questions
It is key to clarify the problem before you start working on it. Some of the following questions can help you gather better requirements:
What are the inputs your system expects?
What is an invalid input and what to do when you receive one?
What output do you need to produce?
What is our service level agreement (SLA)?
How many users do we expect?
How many requests per second?
Do we need to deal with internationalization?
Do we need strong consistency in our database or is eventual consistency enough?
Sometimes you will not have all the information you need to start solving the problem. Chances are no one will and it is your responsibility to figure it all out. The moment you start taking this type of task you will know you are operating at a senior level.
14. Design on paper first
Use pen and paper or a whiteboard to sketch a solution before you start coding. Unless you are solving a trivial problem, try to come up with different alternatives. Then, try to break your own design. Ask yourself questions like:
Where can the system break?
What are the bottlenecks?
Are we relying on third parties? What happens when something goes wrong on their end?
-
Can we use a cache to improve performance?
- What is an appropriate TTL?
- What is the worst thing that can happen if we temporarily serve stale content?
How can we log and monitor the system?
Document your choices, the rationale behind them, and potential risks.
Bonus tip
I think I read this somewhere in an internal wiki page, but it helped me see where I was falling short.
15. Do not be a one-trick pony
If you only know how to do only one thing, it is likely that you have gaps in other areas. Learn other programming languages. Create some machine learning prototypes, even if you are an Android developer. If you are a front-end developer, learn about backend or dive into the internals of Linux.
You don't need to become an expert, but you will an appreciation of how the different pieces fit together. You may learn a thing or two from other areas that you can apply in your career. You may find that you love something new you had never tried and change careers!
PS: I hope you found this useful. If so, like and share this article, visit my blog www.yourdevopsguy.com, and let's connect on Twitter.
Top comments (11)
The most important thing is that a senior developer should understand which things aren't important.
Junior developers don't have the experience to judge this, and so everything seems critically important -- you'll often see Junior developers get into heated arguments about things which just aren't important.
Most things don't matter most of the time, but it takes experience to be able to see which things actually do matter, and where.
Absolutely. Seniors need to prioritize tasks and decide what brings the most value to their team.
Another important one that I sometimes still struggle with: learn to delegate. As you need to focus on more important tasks you need to put aside the ones that are trivial or do not require your whole skill set, but that still need to be done to fulfill the big picture.
To earn trust you must give trust in return. Find the most suitable person among your teammates and colleagues to perform such tasks, or even a junior dev whose skills and knowledge would benefit from fulfilling it, even if you need to put a couple of hours into teaching or supervising them. In the long run the payoff will be worth it.
X) Think long and hard before you write any code, maybe its just easier and cheaper to buy it for $5 a month to verify proof of concept.
Bonus: Know the basics of computer science, not just programing: qvault.io/big-o-algorithms/
Thank you for these recommendations.
Happy to share my experience to help others.
Honestly? Age. It's been this way everywhere I've worked in 25 years as a developer
You are right, there is a correlation between years of experience and being a senior. However,
You need to push yourself to keep growing. It is a mix of experience and attitude (leadership).
Very inspiring and educative write up . I have learnt a couple of things I most tend to ignore
Glad you liked it and found it useful.