In all honesty, I find it very pretentious of myself that I write this article. However, just today I read an article on medium which had the same topic, and it was just so wrong in my opinion. What the other article confused were different concepts, and it valued experience more over problem-solving skills and motivation. So I thought I will drop my opinion here. In this article I will not tell you that you need to love what you do or be motivated, I take that as given if you opened this article!
Why does this even matter? 😎😉😋
Programmers are often proud of their work, because very often we solve a problem for the first time in our life. This makes us proud of ourselves and of the work we have delivered. Due to self reflection, we then usually want to compare ourselves to others to get a sense for our "standing". Many people would argue that being proud is imporatant to be a good programmer, my personal opinion is that you need to be proud of your work to even have the motivation to be good at your work (not only for programming).
But being proud of our code can actually be also in our way!
1. Not open for criticism on our new solution
If we have solved a very hard problem for the first time, guess what chances are that there are much better solutions out there. However, we have put our time and effort in writing this (cough peace of garbage) implementation. So if now a colleague walks up to us after we have submitted our PR and starts to directly give "good advice", it is important to take a deep breath 👼 stay open to their ideas. Even if it is your first year junior! Being open to the opinion of others lets you improve drastically and learn a lot. If you have valid arguments against their ideas, it is a moment where you can teach your colleagues. So either way, a person will probably learn something. However, if you are just going to ignore their comments, then you will lose the opportunity to improve or teach. So be open on your PR and your code will become much better. None is a god programmer and if you think you are you might wanna change your attitude.
To improve this ability it is often simple enough to tell yourself "to be open" before you go through PR comments.
2. Being able to read others people code 🌜🌛
I often see people implement a feature twice or even more often, because they are not able to properly read others people code and use their implementation. So, it comes easier to them to implement the feature from scratch or pull in a new library instead of working out how the code base handled functionality like this before. Or sometimes the current feature is not 100% what they need, so instead of refactoring the current solution to make it more generic and reusable for even future features, they fall back into the bad habit of pulling everything off by themselves. Many of us have started to code alone, without any team, so when people then get started they actually never have read complex implementations from other people.
I mean it is fair enough, often a project has a certain style (or worse no style 😷 😵) and every developer has a certain style as well. Hence, big companies have often such rigid code guidelines.
To improve this simply take more often the harder path and read the other's code properly on a feature request and try to reuse what is there and if required properly refactor it. Often you can also simply see who has committed this piece of code and maybe asked for some initial guidance. I promise if you are going to do this, you will see drastic improvements in your productivity and quality.
3. Grasping the bigger picture 🌌🌌🌌
Nowadays, applications are growing more complex, so it is often hard to understand every detail of an app. However, I think it is crucial to understand the bigger picture. To understand the bigger picture I think it is important that you categorize the "products" or services your company is offering into three sections.
Services and the level of understanding a good programmer has to them.
- Directly work with this service 💻
- Require Data from this service 📞
- One or more Service hops away from my working area 📡
(1) A service on which you are directly working on should become very well known with time. So even if the app is so big that you cannot know all parts of it in detail, at least you should be able to tell where the start of an API is and what the expected outputs are. This helps you to understand the application flow and something like your request or event life cycles. Once you have this internalized, it will become much easier to debug the overall application. Because you know where to start and how to climb down the logic.
(2) If you are just requiring data of this service, you should grasp the overall workflow, like how is authentication set up, so I can use the service or how is the overall API Schema to quickly evaluate newly added or reworked APIs. Often APIs are being added or reworked and a particular someone has forgotten to update the god damn documentation! Again!!! 😡😡😡 But if you know how to deal with the API (and given it is a half way decent API 😅) you are likely to figure out what has changed.
(3) If you work at such a big company that you have a microservice structure like Netflix, then it becomes very hard to exactly know how every API is working. But this brings me back, to knowing the overall picture. What you can easily know is what does this service (inputs and outputs). Once you know what all services do, you can often draw a picture in your mind (or literally draw it if it helps you) to understand what the overall flow is. This helps you to understand if for instance a level 2 service is breaking because it requires data from a level 3 service in the wrong way. Then you can much more effectively create an issue report. Better issue reports are als being valued by your colleagues (FYI 😉).
4. Use the provided tooling 😩😩😩
I think it is crucial to understand what tooling your company uses and at least how it can benefit you as a developer. I see more than often, developers ignoring tools that their company is providing to them. Tools which have been build or are being paid much money for to improve the developer experience. Why do they ignore it? I think often it is that they are not interested in learning this, because it works like they are doing it currently. Often they cannot see the benefit it will bring them, and only see the effort they need to invest in order to learn the tool. And in all honesty, who can blame them? We developers are having a lot on our mind and are constantly learning. But to be more productive it is important to use the tooling which is provided and if it does not suit you should ask to improve the tooling. A great developer will have their tools ready to use. And if you can share these with others, even better.
Let me give an example here, maybe your company use Axiom or Elastic for logging http requests. Then it should become second nature to utilize this for your debugging process. Or you have well-made docker container which ships with a debugger? Then stop using prints and use the debugger. Ah and did I mention that a debugger is awesome. I wrote btw an article on how to set up Laravel in docker with a debugger you might want to check that out. 😄
Even more importantly start using a debugger!!! 😒😒😒
It is unimaginable, how often I have solved an issue within a few minutes, where my colleagues have struggled for a long time, simple due to the fact that they used prints instead of a debugger.
Debugger = King ⚡⚡⚡
5. Putting in the effort to learn the frameworks your company is using
I think this is something which is often true for smaller companies or some freelancer, which often work on a tighter belt. Frameworks are there to help you, so take that help and stop to implement your own shitty solution. If a part of it is not perfect suited for your needs, you might want to simply extend the framework. But in order to do that, you need to understand the framework.
I know I know, Frameworks have opinions, and you may or may not agree with them. However, if you are using a framework, please try to stick to the framework's opinion as closely as possible. Probably smart people have thought something of these opinions 😛.
If you are not feeling very strong in a particular framework or library, but you will need to use it, please spend the time to learn at least the basics. I think if you are going to be open to your lead or boss that you will need 2 to 4 hours learning a framework which you should extensively use, then almost none will decline your request. If they will you might wanna look for a better learning enviornment. 🔎🔎🔎
LET ME KNOW 🚀🚀🚀
- What is your top 5?
- Did you like the article? 🔥🔥🔥
- I appreciate any feedback
Top comments (4)
That's a great take. I also find it kinda weird when being good is minimized with have experience because I don't think that's enough.
About the first point I think sometimes is really linked with ego, so maybe not only being "open" but to remember that any feedback: in PRs, in performances reviews etc. are not personal but a way just to keep on growing
Yes! I am totally with you there. I have met so many people who work in the filed much longer than me, but do not put in the effort to learn their profession properly.
I would have called point #5 "RTFM: Read the f*cking manual" but overall this is a well rounded post on characteristics that are becoming of a good engineer, well said!
@theaccordance
Indeed, this would have been also a very suited title :D
Thank you for your feedback, appreciated!