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.
1. Prototype
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.
3. Time
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.
5. Repetition
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.
And you?
Do you also develop programs and have some habit that you usually follow? So share it here down in the comments.
Top comments (9)
I blog, with the goal of one article per week.
I talk about software I use, so by writing articles on them, I have to do research, and usually I learn a thing or two.
It works really great when I blog about my configs. By trying to explain my choices, I found I end up with cleaner and more coherent set ups.
And here's an example of that:
fzf for the win
Be involved in a engineering community. In person is the best option.
Find a mentor, someone who teaches well and willing to answer questions and bounce ideas around with.
"Design First" might send the wrong message. If your design is more than a very rough archtiecture then it'll more likely get in the way than be helpful. Detailed designs are generally not helpful. Langauges, and libraries, are high enough level now that you can easily think about desing while coding.
I'm not certain multiple prototypes are really that helpful. Actually, I've rarely done much prototyping. I see no reason why you'd intentionally build code to throw out. Why not write code with the goal of needing lots of refactoring? This isn't to say some code won't be thrown out, but why make that the goal?
I do believe in automating as much as possible, but I must say I don't use an IDE.
Always Document
Documentation before coding helps highlight the main purpose and reason for your programs or software. It shows the problems you are solving, as an engineer you should always be able to solve a problem not create more.
Learn JUnit! My very first advice! The best advice!
I have seen developers who start the hard way, by developing classes of 3000 lines and then they compile everything, deploy their stuff in a server and start debugging. Once one of my colleagues said "you should remove the debugger from eclipse in order to make them better developers". And he was right!
Begin always with a JUnit. It is not more work as one would expect, because it helps to break down your code in testable units ... and here is the "divide and conquer" tip applied in the best possible ways. If your code works well in a JUnit (or let's just say Unit Test, because you can do this not only in Java, but also in JavaScript, Python, C++, even Assembler), then it will work on the customer PC as well or on a server.
And if you make little changes, you will not fear that you forgot to test some part manually. The JUnit will tell you if it still works.
Great article.
For me, I read the requirements multiple times to ensure am doing it right. Most of the times it comes in plain language to continuously reading it helps me understand better what the user is saying.
Also at each stage of the development process I cross-check with the requirements. This also gives me ideas which I can pass on to the user and if they like it that's done as well.
Techniques and stuff you need to know:
I always like to find the repositories of the libraries that i use and read their source code.
This helps me learn more about the library and learn design patterns and concepts that used by someone probably more experienced than i am.
I also like to take on a common problem try to solve it myself and then find how enterprise level libraries solved it. Doing this not only i learn what was the main problem that was solved but its pitfalls too.