1. Leave the ego at the door
Developers have bloated egos. It is a fact. But why? I would say that anyone who is serious about their profession considers themselves to be something of a person of art. Yes, we do not sing in front of millions and do not draw "Mona Lisa", but sometimes we write code that solves complex problems so efficiently and elegantly that we cannot help but be proud of our work. I think that a developer, by his approach to problems, is as much a man of art as a mathematician is. As such, we tend to crawl around the code just like a mother bear around her offspring. We write it, love it and hate it when people around argue about how wrong the code is or not.
On the other hand, it hasn't helped anyone yet. We love our job, but we must understand that we are solving problems. In discussing our ideas and solutions with other people, a better alternative may arise. There is nothing wrong. In fact, collaboration tends to yield better solutions. I have watched all kinds of ego, but I have never seen a situation where the ego would work for a developer.
What advice can I give? From the minute you start working as a developer, leave your ego at the door. Swallow it and listen to what other people have to say about your work. Accept that the best ideas may not be in your head and that they can enhance your professionalism. You will only benefit from listening to the feedback.
2. Languages are a tool. Do you only know the hammer? Then all problems are like nails
Stop calling yourself a Java developer or JavaScript developer. Yes, there are languages that you like because of their syntax or capabilities. This is completely normal. However, you win if you spend some time studying something else. Learning new languages, especially if they are following a different paradigm from the one you are used to, can open your mind to different approaches to problem solving.
I don’t even know how important this is: learning new languages and applying them will benefit your skills. I read the book Seven Languages in Seven Weeks a few years ago, and it opened up a lot of options for me just because it showed the problem solving methods available in other languages.
We are developers. We know how to solve problems with code. Don't limit yourself. Look beyond the limits, think outside the box, learn other options, languages, ways to solve problems. Even if you don't do it for long, you will return to your familiar tool with fresh ideas and broader thinking.
3. It's not about memorizing algorithms, but finding them
Some newbie developers think they need to know the algorithms by heart, so they feel bad the minute they realize they've started to forget how to write the for loop. This is not only normal. I would say that it is even useful. We just have too much to remember. But this is also unnecessary. We have to accept that the Internet is just another tool as needed as our IDE to find answers.
We all do this. And if it makes you feel bad, don't waste time on that feeling. Just search Google for the answer and understand your problem. Think about this. Each language has similar, but slightly different, ways to implement the Observer pattern. What's more useful? Understanding what a pattern is good for and what problems it solves, or remembering how to implement it in each language you work with?
If you know that the pattern will solve your problem, then you have already solved it. Everything else is just a search for the best way to implement it on Google. This search takes away no respect for you, your work, or your experience. The same applies to any other search. Focus on what's important, solving the problem and let Google push your memory. That's why it exists.
4.
Or rather, you have to study for your entire career. The decision whether you follow the latest developments in the industry is up to you. But it's best to do this if you want to match.
Languages and technologies are evolving, and that's perfectly normal. Of course, some ecosystems change faster than others, and keeping up with them may seem like a titanic task, but focus on the important things, remember that you are only human and cannot know everything. Therefore, if you need to learn one thing, I suggest learning to learn.
I know this may sound silly, but maybe the developer has this skill number one. We must learn to learn new skills quickly. Otherwise, you run the risk of getting the "outdated" label.
This is where some of the other lessons in this article come into play. Variability, change, new challenges, lack of ego - all these will help you learn and expand your range of skills. The more you practice it, the better. Eventually, you will find that all languages are similar. You will begin to see their common roots and be able to work with any of them. All you have to do is read a couple of key things. Throughout your career, you will study:
- New languages.
- New (and old) programming paradigms.
- New approaches to work.
- New ways to solve problems.
- New ways to interact with teammates.
- New approaches to reviewing and testing your code.
If you are not ready to be an eternal student, consider whether such a career is for you. Notice that I did not say, "Leave immediately," but consider whether you are ready to open your mind to continuous learning.
5. Works better than ideal
As a manager, I've heard this too many times. But as developers, we tend to think that the code should be perfect before release. And this is not only untrue, but potentially a problem. Optimizing early is a problem because you end up spending a lot of time and effort on things that may not need to be optimized. And in some situations, when doing this optimization, you make assumptions that break the functionality.
So focus on the work to be done and the problem you are trying to solve. After solving the problem, test it, iterate over the results, and see what your team thinks about your solution, even if you can already see ways to improve it. If you're going to spend two more days just making the code perfect, but it might go into production right now, chances are it should be in production right now.
In the end, you solve the problem. The faster you fix the problem, the better for your users.
6. Make the code work, then optimize
According to some of the previous points, don't fall into the early optimization black hole. Even if you think you’ll get the code fast, once it’s out (if it ever does), you’ll find that the time dilation effect is real.
Your first priority as a software developer writing a new feature or fixing a bug is to make it work, no matter how ugly the code may look or how inefficient the solution may be. If the code works, you've just proven that it is possible to write code. This is half the battle.
The second step is optimization. This step is optional. Details that some people tend to forget. The time you have at your disposal to optimize your code depends on many variables that you sometimes do not control. So focus on getting the code to work and then figure out if you actually have time to optimize it.
Optimizing early means optimizing your code as you write it. This is a dangerous practice because when optimizing we make assumptions about runtime, data requirements, memory requirements, and other factors that we have not yet seen in action. Any such assumption can be wrong, and eventually you will introduce errors into your logic.
Think about the TDD workflow:
- Write a test to understand everything that needs to be done for your function (the test will fail).
- Write your code so that the test passes.
- Now worry about optimizing your code.
The second step is required. First you need to take care of the test, which means the function is working. The test doesn't care that you use three nested if statements in your algorithms. This will become important, perhaps at the stage of code review.
7. The last 10% of the project takes 90% of the time
This is especially important if you work alone, but teams also suffer from not getting this little mathematical detail right. Anyone who has completed a project will say the same (and frankly, this is not just the case in our industry). First, you rush through a lot of details to think about later.
And this is completely normal. We tend to focus primarily on large features, leaving small details or even known bugs to the very end. But nevertheless, you need to fight them - and here an additional 90% appears. You have to test, fix the code, test again, teach users how to handle the solution, submit the final version of the solution, and so on. Of course, it all depends on the context, who your client is, and many other factors, but there is always something. So remember, when you think you're almost done with the code, you probably forgot something.
8. When you're on a team, you need abstraction.
Coding is about the behavior of abstractions. By abstracting common logic, we can reuse it elsewhere, but in the beginning we forget the importance of abstractions. Here's my personal rule: if the code is repeated in two places, it is sent to a function (method, module); you get the idea. If two repetitions look like a small number to your eyes, keep in mind that there may be other places in the future to apply the code you just abstracted. And by abstracting the code right away, you will immediately have access to it.
Abstraction is scaling. A piece of abstract logic can be used many times with minimal effort, while copy-paste (although it's easy to do) - the more you use it, the more effort it takes. Think about what happens if, due to a bug, you need to change a piece of logic that is repeated 5 times. To fix a bug, you literally change the same part of the code 5 times.
The same logic applies to everyday tasks. If you do something more than once, it can probably be automated in some way. This is the key to efficiency, so look for repetition not only in your code, but also in your actions. If you automate a task that takes 10 minutes a day, you will save 5 hours in a month.
9. Side projects are optional, but can help
Some say that if you want to be a successful developer, you need side projects. I don’t think this is true. I personally know many great developers who only write code at work, "from 9 to 17". To be honest, I admire them. They are masters of their craft, and in their free time, doing something else, they enjoy life. There is absolutely nothing wrong with that. However, sometimes you need some extra practice. Sometimes you feel like you are lagging behind your colleagues; here and help side projects.
I'm not talking about a revolution in the industry - developing a framework with millions of users. Write it if you want, but I'm talking about copying someone else's projects to learn from them. I'm also talking about contributing to other people's projects, fixing bugs, and adding functionality.
You can write side projects to experience other aspects of development that you would not normally touch. If you write unit tests 8 hours a day, you might think about writing something from scratch or developing some functionality. If you're tired of working alone, contribute to an existing project of others and experience what it means to coordinate your work with others. You can write a side project to improve your skill level by addressing weaknesses. But then again, don't feel like you need to work on them with a green Github activity bar to be considered a serious developer. This is just silly.
Conclusion
Here are my 9 hard lessons as a developer over the past 18 years. Hopefully, by sharing my experience, I've shed some light on your future or current career. Have you learned something else that you would like to share? I'd love to hear from you in the comments, I'd love to learn something from you.
Other professions and courses