There is no hard and fast rule as to how a programmer should program. So, there is nothing wrong if you have your own style of programming.
There is no fixed set of habits for a programmer, but I would like to mention some of the behaviors that hamper the progress of a programmer.
And here are the top 5 habits which developers should avoid to climb the ladder faster:
1. No code structure or code style
Agreed upon larger-scale code structure (architecture) and agreed smaller-scale code style is a must thing. Sometimes programmers start with a project without defining these, and, as a result, when the project goes wide and large, it becomes difficult to manage it.
Moreover, the code structure and style helps in certain conditions when more than one programmer is working on the projectβit is easy to handle the code management.
2. Copy-pasting code blindly
We all use code off the internet, no doubt.
In fact, not reusing code is not the smartest idea. But every time you use some code, do you blindly paste it and check if it worked? Well, if yes, you are missing an opportunity to learn.
The reason you looked for the code is that you either did not know how to do it or you wanted to save time. Attempt to understand the snippet that you used at least at a high level. You do not have to follow the code line by line but at least understand the approach used.
The next level is to reproduce the same solution from scratch. Maybe even make it simpler. This way, you'll get the most out of this.
3. Staying late nights
Most programmers are night owls.
That usually dates back to the fact that most programmers would always program late at night, cause less focused (or more proactive) programmers are on during the day (more time to debug and compile without saturated servers), and no meetings.
Why nights? Because nights give the chance to be alone, and just straight-up program. That's why usually programmers are most productive during the late-night hours.
Feeling productive though doesn't mean we actually are. What if all this work will have to be thrown away and reworked? Because of the new information tomorrow morning when talking with your colleagues?
Also, developers still have to go to work in the morning. And staying late at night, in this scenario, will accumulate tiredness and stress. Without (stable over time) good night sleep, mental and physiological issues will start to pile up, which could create negative self-reinforcing cycles of burnout, depression, sicknesses, etc.
The solution here is to get a good night of sleep regularly, be refreshed, and learn how to be productive and focused during the day.
4. Lack of documentation
Thinking that documentation is a burden and should be pushed on the back burner when possible and rushed when it's not.
This causes technical debt and is the main hindrance to onboarding a new developer onto the team.
If people put more effort toward documentation, then better processes would be created to handle this.
This would begin to increase the ability to cross-train devs quickly and efficiently.
5. Writing code without tests
Putting aside the debate about the pros and cons of TDD, having some tests is pretty much a must.
Some prefer to write them first, others write the tests afterward. Either way is better than having no tests at all.
Having a good test coverage encourages developers to make changes more confidently, and with fewer bugs, and fix structural problems in the code more often. Which, in turn, improves team speed and allows for more value to be delivered to the end-user.
As of now, just pay attention to these behaviors and try to correct your habits, once it becomes a pattern in you, you will automatically know what works best for you.
If you want to learn more about how to succeed in dev careers without stress, find useful tips in my weekly newsletter, along with your FREE Professional Networking Cheat Sheet.
Thank you for reading! π
If you have any thoughts on this post, feel free to reach out to me on Twitter, and leave comments below.
Photo by Basil MK from Pexels
Top comments (25)
On the topic of documentation, I'd say that using Doxygen or some other API autodoc tool is not the solution most people think it is. Useful documentation almost always has to be written by hand, otherwise it's like teaching someone to use a toaster by explaining the electrical specifications of the heating element.
Regard "night owls", I find that getting up earlier (5 AM for me) gives me time to ease into my day, get a bit of work done in the quietness of the early morning, and yet actually help my productivity for the rest of the day. Being an early bird or a night owl is a matter of choice and practice, not biology. You can decide what to be.
Waking up at 5 AM is more than just getting things done π
5AM huh? What time would you usually go to bed? I'd love to try this for myself.
Personally, 10pm. I typically only need about 7 hours of sleep to be well-rested. (Just to make up the difference, I sleep 10pm-7(:30)am on weekends.)
If you find you need 7.5 or 8 hours of sleep, you can shift the bedtime or wakeup times around, of course. This week, I've been unusually tired, so I've been doing 10pm-5:30am or 10pm-6am.
Agree with everything you said!
I can't believe there are people that think tests are pointless. If they hate tests so much, they can go and test every single feature for each change they make. That might change their minds π
Many thanks! Writing tests makes life easier for software developers π
They believe they are so smart and so good that they can't possibly make a mistake and introduce a regression.
Moreover, when this happen, they'll blame everything around them, but not themselves.
There's an underappreciated difference between feeling productive and being productive. That's particularly true when you feel you're in the 'zone' (Uncle Bob himself discussed that point in The Clean Coder).
Brilliant blog, I agree with it all. I particularly resonate with your chapter on staying up late and being a night owl, I used to be so bad with this, coding till the early hours. It wasn't until I read Why We Sleep by Mathew Walker that I actually started to realise the importance of sleep!
Thanks a lot for your words and the link! π
Sleep is essential!!
First or all, It's a great article and I haven't finished it but have, on the others hand, saved it for later. The funny thing is, when you're younger you feel invincible and don't pay attention to your sleeping habits.
I belive this is especially prominent in software development community or maybe it's IT in general. I felt the need to comment since I've been doing dev for around 20 years, started when I was 16.
In the old days, I would sleep maybe 2 to 4 hours a day, and would stress myself to the point of almost collapsing.
After weeks of this torture, my body finally decided to put a stop to all this in a form of grand mall epileptic seizure. And there you have it.
If I hadn't been so reckless about my own health, my daily routine would not include taking two types of pills twice a day.
This is just my unfortunate experience and it doesn't happen to everyone but it could happen to you if you're not careful. Times have also changed, for the worse of course; now it's even more stressful and people are pushed to work even harder.
Go to bed before 2am, get at least 6 hours of sleep, it will increase your productivity and maybe spare you of any potential health issues.
Cheers,
DF
Check this great article:
Want to be a better developer? Take care of your sleep!
Damien Cosset γ» Jul 4 γ» 6 min read
I have fucked a lot of people over not documenting things. There have been jobs where I had a bus factor of 1, and when I left I was being a self-centered ass. There were a lot of other things going on in my life at the time so I'm learning to forgive myself, but it's a lesson I have taken to heart.
Point 3, third paragraph, that could happen even when working on daytime. If you feel productive you probably are, though I agree on the point that we are design to live at day and sleep at night, plus the rest of the society also is. That's why is better to be productive during daytime.
Thanks for putting the time on this article.
Thank you for your thoughts! I am happy you liked the article.
I use Doxygen but that is low level documentation used primarily by developers. It's only useful in combination with a hand written higher level overview documentation. What's the point of knowing how a spark plug works if you don't know how to start or drive a car.
Also, it makes me cringe when I see stuff like "the code is self explanatory", etc.
I highly appreciate developers who take their time to write user level documentation, which is, in my opinion, vastly more useful than describing function arguments and return values.
LaTeX is my preferred tool for high level documentation, while Doxygen serves the purpose of being API documentation tool.
Regarding code style, I use ClangFormat since I'm a C developer. It's a great tool to keep your coding syle consistent. Another similar tools which I used while writing Web apps in React.js is Prettier; it is highly configurable and probably supports a plethora of languages.
Very glad you included testing as that for me is probably the most valuable. There have been plenty of times when a regression test has quickly saved me.
And thanks to test coverage now you are not afraid of changing code while refactoring or new feature implementation π
Are tests not enough documentations? In addition I got lot of devs saying "well you wouldn't need test if you just code better and you'd code better if you understand every single little thing in the system like I did". :\
In my opinion, it should be basic documentation for the project with the project description + architecture, setup, run, and deployment. Truly understanding of the project comes during the work on it.
Some developers might be lazy to cover the software with tests and they are looking for excuses not to learn it π
Guilty of point 3.
Also guilty for being loud in the office. I work in a scrum team and we are the loudest in the open space, not to mention arguing and throwing sexist jokes. I think that if my team had at least one female dev, we'd nicer to each other ;)
"Having a good test coverage encourages developers to make changes more confidently..."
How many % of the codebase should be covered with tests in your opinion?
It's not just a number.
It's also the importance. The more important the bit of logic (and the more other modules depend on it) the better it should be tested.
Looking at a single number is not productive because you can always increase coverage by adding more tests to not-so-important code.
Add excessive smoking also!!!
Still guilty of point 3 :(
To think you are the smartest person in the world sometimes becomes a bad habbit of developers also. π