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...
For further actions, you may consider blocking this person and/or reporting abuse
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.