Whenever I’m asked what I do for a living, I often say I am a software engineer. But am I really close to being a good one?
I looked around the net for some tips/pieces of advice to becoming a better software engineer and I got the following:
- You’re paid to THINK. by Eric Hexter
If you normally get your requirements verbally, try writing them down.
Write down your requirements or technical plan in the easiest manner possible. That could be on a whiteboard, you could annotate a screenshot of an existing screen, you could use pencil and draw the changes to a print out of a screen shot. Just do something in terms of thinking about what needs to be done before you start typing. If you do write down what you plan to do, you can actually communicate it to other developers. You can have someone else review it and think through the problem. You can also show it to the person who will decide if you created the correct software, imagine getting some feedback on what you want to build before you mess it up?
The two most valuable ways I have found to write down what needs to be created are Screen Mockups and Sequence Diagrams. Now, I have been in the web space for a long time, so if you are not creating websites, or web applications, you may find that there are better ways to write down what you need for your particular design problem. Either way , try to write it down. If you are writing mockups today, then add a sequence diagram for the more complicated problems and see if it helps. I know it helps me and the developers I work with.
- Go, Solve Problems by Derick Bailey
I’m paid to solve problems consistently and reliably, and either implement the solutions through software or recommend a solution that doesn’t involve software. If I solve a problem once, but the solution breaks or is not repeatable after that one time, I have not done my job. If I solve a problem 100 times, add more code to try and solve a second problem and end up breaking the first solution, I have not done my job. My job is done when I can consistently and reliably solve the problem in a manner that either adds value or reduces cost. You are not paid to write software or tests. You are paid to solve problems and you happen to do it through software (and tests).
3. Learn to deal with people by John Sonmez
The basic problem is that humans are not logical creatures, we are emotional ones. Sure, we like to pride ourselves on our ability to reason, but the reality is that most decisions we make are more influenced by emotion than reason.
What this means for you as a software developer is that unless you can effectively deal with other developers, managers, and even customers, you will constantly face trouble despite how good your ideas are or how valuable your skills are.
Being active and involved in the software development community in general can also help you immensely in your career. It is not just about networking, but getting your name out there and building good Karma.
4. Understand the business of your customer by Markus Sprunck
How can you design and implement good software without deep understanding of the purpose or use? The answer is easy: “If you don’t know the WHAT, you can’t decide about the HOW.” A deep understanding of your customer’s and/or users’ businesswill lead to better requirements, designs, implementations and tests.Most of the software’s functionality creates no business value. The challenge is to select the functionality which creates business value. The better you know the business the higher is the probability to implement the best system.
5. Don’t Trust Code without Adequate Test by Markus Sprunck
Ten years ago, I trusted my code. Why not? After 8 years C++ with excellent skills and a lot of experiences. I just coded, tested and everything was working well. But over the years I made and saw a lot of errors. Because of these errors, I lost the trust in my own and others code.
Today, I don’t trust code until it passed:
- unit test,
- integration & system tests,
- checks of performance and memory with real world data,
- static code analysis,
- measure code coverage of test,
- load & stress tests and
- peer review.