There is more to software development than writing code. This post describes three of the most oft-repeated tasks I have been asked over the years. These are not strictly programming tasks but help magnify the impact.
1. Documentation
As a grad student in 2012/2013, I set up a continuous delivery pipeline on AWS for my team of three. It was quite complex, leveraging git hooks and remotes but it did work – a git push would deploy the entire site.
I didn’t document the pipeline though; why spend time writing pages when the scripts existed? Who needed documentation when you could debug scripts; that was too ‘easy’. The irony is that I would have been the first beneficiary of the documentation.
Looking back, I was wrong, quite wrong; I should have documented the pipeline, especially its kinks. It was difficult to get my teammates to extend the pipeline and I also got confused when I went back after a few months.
There are very few successful projects without good documentation. Excellent guides help everyone; they make it easy for new developers to ramp up and provide a reference for other engineers. Well-documented projects save engineers time – folks can always read the manual; furthermore, they make it easier to transition projects to new owners.
Sometimes it might feel like overkill writing documentation if you’re the sole developer on a project. Still document though. It’ll help you when things get confusing (trust me, that’ll happen) and is also a great benefit when your team grows and you have to bring in new folks.
2. Testing
What do I need tests for? My code works™.
Tests take time to write, they need to be updated when code changes and their return on investment can be hidden. However, their many benefits outweigh any of these costs and one of the hallmarks of great programmers is writing tests.
A few benefits of testing:
- Safety net: Tests allow engineers to refactor and make huge changes without worrying about things breaking. If there is adequate coverage, then some tests would fail. Saying 100% test coverage is
too expensive is no reason to have 0% coverage. Tests not catching new issues? Yes, add in regression tests to prevent them from happening again. Tests too brittle? Re-think your testing strategy – there might be hidden dependencies. - Living documentation: Tests (especially unit tests) offer living documentation of how features work and explain the true intent of the programmer. Documentation can easily get outdated if not maintained. However, tests can be expected to match the latest code if they pass.
- Find issues with code design: Tests can be very effective at rooting out issues in code. Null references? A unit test will most likely fail fast at initialization time due to weird defaults. Poorly-designed code is usually very hard to test. So if tests are difficult to write, re-consider the original code.
Warning: if you have a hard deadline and decide to forego tests to meet the ship date; then two things can happen:
- You’ll ship a lot of bugs and spend a lot of time trying to fix issues
- It’ll be almost impossible to reverse the cultural damage and perception that decision would cause. Engineers on that team would have gotten used to shipping without tests and reversing that culture will be expensive.
3. Mentoring
Help others grow and excel at their job – you’ll become better for it too. You’ll improve your listening skills, become more empathetic and learn new things from your mentees.
Why else should you mentor? It helps junior engineers learn from your mistakes, this enables them to become successful faster without making the same mistakes. Moreover, as a mentor, you get to reflect on your decisions and introspect; and that’s a key leadership trait.
A lot of engineers gripe about the time spent on mentoring and growing new engineers. They complain about the time effort and interruption costs. While there is some ramp-up cost; the investment eventually pays off. As mentees ramp up, they become more independent and can be trusted to deliver on challenging projects. Moreover, they can provide new insights and inject new ideas into stagnant processes and projects.
More importantly, it is amazing seeing people grow and become better. This is also another way you can give back. Finally, you get to learn how to communicate, express ideas and achieve results through others.
What other high-impact non-coding tasks do you know about? Share in the comments.
CodeKraft 
Another inspirational article. I would just like to add that end user documentation is important too. It’s usually pretty easy to break the best systems by putting the wrong (but acceptable) data into them and by misinterpreting the results from good data.
Quality end user documentation is particularly difficult to produce because the builders are too close to their systems and understand and assume many things that an end user may not while business analysts may be too far from the details to produce accurate results. This requires an extra level of clarity and being able to see the systems from the outside – as end users do.
LikeLike
They are high impact but they are only valued in places where people want to/can do/are evaluated for doing a good job (appearances are everything post-2007). I do documentation that later someone “polishes” to claim credit … I fix bugs that other people create and it is in their interest to minimize my contribution.
IMHO, the previous answer is significant of another malady, silo specialization and not being able to see the whole picture: too many people try to insulate the ones doing the work from one another so that they can be managers and mess everything up, blaming later the “builders” which are now required to work at all levels: from infrastructure to front-end, back-end, testing, quality, documentation, second or higher level user support … All except having direct contact with: users, clients, potential partners, decision making people … visibility. I’m calling it quits! We have twisted agile into groupthink, it is 1984 all over.
LikeLike