Hi I’m Tom, I’m a Software Engineer

Hand in hand with things to look out for in working with Unity, are things that I have noticed from being a Software Developer and Engineering Manager in my career, hobbies and day to day life. Below is a compiled list of some of the key philosophies I have picked up along the way about Software Development in general, which is often painful common sense in hindsight but could make everyone’s lives in a project a hell of a lot easier, if applied consistently. I typed this late at night so hopefully this list does not come across as too preachy or too much of a rant! In no particular order:

1. Elegant does not mean complex: There are developers out there who look at algorithms as a means to show off their knowledge of a syntax, their brevity in SLOC or there precision in selecting obscure data structures. Making something clever or complex does not equal making it easy to maintain or understand. Often the time spent finessing an algorithm to be as minimal or syntactically brilliant as possible would be better spent in choosing a more understandable set of variable names or breaking the same algorithm into multiple lines within multiple more meaningful and unit testable methods.
2. Be Predictable: In most projects, where budget and schedule are key, being predictable in your estimates, hours of work, scoping of tasks and performance against Story Points / ETCs / SLOC is much more helpful to your team and your team leads than just being faster / better / more knowledgeable in a subject. It seems a lot easier for some developers to learn an area and speed, than it is to learn discipline and predictability in their work. Being quick but erratic can lead to: similar feeling tasks being wildly different in completion rates; a focus on speed rather than maturity resulting in increased rework; a tendency to cut corners when things aren’t progressing as fast as your fastest tasks. Unpredictable burn speed can also impact the wider team in not having enough work in sprints, not having a dependency ready to take on the next piece of work in the chain, not having resource available to prioritise reviewing your work.
3. Be Surgically Precise: A famous old quote from Bill Gates: “Measuring programming progress by lines of code is like measuring aircraft building progress by weight”. I have come across many engineers who just don’t take the time to think and plan ahead and dive right into writing and committing SLOC after SLOC without really thinking about a design, or even a good precise approach to building or fixing a solution. In bug fixing in particular, a one line code fix that is precise is much better than flinging code at a problem to work around an issue. Fix the solution, don’t create a new one (with it’s own new inherent bugs). SLOC tracking, although dated, can be useful in understanding churn in an area. But disregarding large-scale automated refactoring, large SLOC churn in a short time is often an indicator of bad not good work rate. What is the point of being the Usain Bolt of code generation if you are running in the wrong direction?
4. Talking about requirements is not a 90s thing: Requirements work can get a bad rep in this post-Agile age of User Stories and TDD. When you next pick up a task in a project without formal requirements documentation, have a think about the scope of it. Jot down a few things you need to do in your task description. Put some hours against each bullet. Understand how the bullets relates to other tasks for the area. Link any follow on work for these bullets to this task. Understand why you need to do the work and assess how high priority it is. When you complete a bullet, tick it off and make sure your remaining ETC for the work matches the sum for each remaining bullet. What are you doing here? Lower level requirements analysis, tracing and monitoring just in an informal setting.
5. Simplicity of naming and language is key: Software Engineers can be a strange bunch. We work with languages for a living, but often eschew the importance of being clear in that language. Jargon is a fond friend, silly acronyms are means of imparting your wit, methods are often spelt sadistically similarly to each other. Be better! Find an outlet outside of software for this level of linguistic mindfuckery. Understand your audience for who is reading (yes reading!) your code and be sympathetic to their potential lack of experience levels, lack of knowledge of the system, lack of being on the same brain-wave or lack of the nth coffee that you have had that day.
6. Improve yourself: There are a surprising number of people that go through their careers, learning on the job and then plateauing at a level that suits just getting through the tasks at hand. There is a reason that other people outside work are talking about modern technologies, new methodologies and the latest tools. Staying abreast of the latest developments in the industry will make you a better engineer. Don’t wait for someone in your company to pull their finger out, give you a training budget and push you in the direction of a course, go and sort it on your own time.
7. Clean your code: There are a crazy number of things you can do to make your code more understandable, more maintainable and less prone to bugs than other people’s: Read a book on clean code; do a training course on SOLID principles; review your own code before each git commit; if in doubt about a dodgy method, get a peer to have a look at it to see if they can understand it; make sure you have code templates and coding style guides in place for your team; use static code analysis to catch when things are dirty; set up custom rules in your code formatter; look at other coding styles and guides for your language; understand best practice.
8. Be Responsible: I have always compared the feeling of finishing code features to that of completing a bookcase in woodworking class as a kid. Take the time to be responsible for your output. Enjoy the sense of accomplishment from a job done well. Often you can rush things in, chasing the next milestone or sprint goal. Talk to your leads to understand the metrics that you have for the maturity of your product. Pride yourself in the work you produce. Be receptive to other people’s constructive feedback of your output. When you have found or introduced problems in your area or areas you have touched, hold up your hand as soon as possible.