8 habits to become a better software engineer
Rafael Corrêa Gomes May 1 '17
I've read some weeks ago an interesting topic at the Quora, it's a question about how to become a better software engineer. I liked the answers and I guess that it will be useful to improve your techniques of development your skills with these 8 habits to become a better software engineer.
The most positive feedback comes from Jeff Nelson, inventor of the Chromebook. The engineer focuses on creating small prototypes when learning new concepts: in these situations, he writes a few dozen programs, all short, to demonstrate a simple idea. According to the developer, this prototyping makes it much easier to test several concepts in a short period of time.
2. Brick Walls
Another interesting tip comes from web developer Damien Roche, who talks about his set of notes christened Brick Walls. It lists all the more complicated problems of those who require hours of work to solve them together with their solutions. If he stops using the list for a long time, it is because he is not challenging himself enough, and thinks it necessary to look for new goals.
Ed Prentice, a software engineer, is another of the most voted positively, for his list of good habits that he says follow. The first ones revolve around the main point proposed by the developer, saving as much time as possible: automate everything you can get, he writes. To do this, use a powerful IDE, and configure it to do what you can for yourself, create macros for things you do repeatedly, and learn keyboard shortcuts and the UNIX command line, for example.
4. Challenges and teachings
The same Prentice is not limited to automation in its large list of customs. Other tips given by him involve challenging yourself, especially. Never written a web app? He asks, before suggesting that you try doing this in Ruby on Rails, for example. It is also worth teaching something, even if it is not about development, as well as checking the Stack Exchange frequently for topics you are familiar with or not, as a way to improve your knowledge. Finally, sharing experiences and lessons learned is a habit that is also worth adopting.
The user Rafael Buch already brings to light two exercises and habits said traditional between programmers: Kaizen and Kata. The first is to rewrite and reshape, or polish your code like a gemstone. Every time you need to make a change (on the code), re-evaluate the design around it, he writes. The second focuses on writing the same lines over and over again, making careful changes in each attempt. Each repetition will yield minor improvements, and it will be easier to find errors early on that could lead to larger problems later, he says.
6. Divide and conquer
Author and programmer Debasish Ghosh already tries to keep up the habit of reading many good and bad codes. This second part, he says, is equally important, as it highlights many patterns that should not be followed. He also recommends using a divide-and-conquer policy when solving complex problems, starting with the simple, then exploring the more complex parts. Another good habit suggested is to associate with a project, preferably an open-source project.
7. Design first
Ankit Gupta, an Amazon software engineer, says that a valid idea is to think first about design before going to deployment. I agree that there are things that will be solved only during this second stage, but a solid design will leave its concrete architecture, he writes. This advice he admits does not always follow, Gupta is another who talks about process automation, just like Prentice.
8. In search of bugs
Creator of the programs Tune Smithy and Bounce Metronome, among others, Robert Walker is one of those who maintains the apparently obvious habit to write down all the bugs, however small they are. It is a way of not forgetting anything, since small flaws can be left out. Walker also saves the modifications in different .ini projects, as a way to reproduce old problems when it is necessary even if this is never the case. And of course, it also makes frequent backups of the code, so as not to risk losing any of the work.
Do you also develop programs and have some habit that you usually follow? So share it here down in the comments.