Between 2000 and 2026, I worked as a
- Software developer for seven years in a software house on a small bank front office trading system
- Spent six years in a big U.S. bank on their oil Commodity trading software and then
- Eight years supporting a legacy property finance system for small and medium realtors and agencies.
All teams were small with four or five developers and a manager. Here are a few things I’ve picked up along the way.
There Is Nothing More Frustrating Than Slow Responses
A couple of the projects I’ve worked on required working with other teams. One in particular was using a technology I was unfamiliar with and needed the involvement of an engineer from another team to set up and configure things with a bit of hand-holding.
The server they provided was used in production so they wouldn’t make me be an admin for the fear of me bringing it all down. On an earlier project I’d been admin and was able to do all the configuration and figure things out with a bit of trial and error. But when you depend on someone else to do things for you, delays to requests or questions can add hours, even days to my work and it drives me nuts. I was under pressure to deliver and didn't want to lean too hard on the engineer who helped when he could. In the end I got my manager involved, he spoke to his counterpart and that moved things along.
The Best Managers Act as Shields to Protect Their Teams
The worst managers are those who don’t push back when requests come in and you end up having to refocus and reprioritize. The best managers can shield their teams from development requests that would disrupt the work already being done. All requests are prioritized and the highest ones might make it into the next sprint once we’ve worked through the current one. Once we’re in a sprint, we don’t want to disturb it.
Even a seemingly trivial request like changing the font size of a message or its color can be disruptive when you add in the time to create a Jira, write a simple test, get someone to test it etc. Five minutes becomes a couple of hours and risks the sprint not achieving its goal. Only urgent production changes such as a critical bug fix get through. Otherwise, it’s a no.
Avoid Clever Code If You Can. If You Can’t, Bundle It Up
Every programmer wants to write ingenious, elegant code - but while that’s fine on a personal project, on a business project you need to hold back. It’s not your code and the next person working on it may need to fix or amend it, not spend hours scratching their head trying to understand what you did. Plain and easy to understand code is what you should aim for.
Sometimes though, complicated code is unavoidable. All you can do is pepper the source code with comments, document it well and provide examples of how to use it — whether it be an object or a function. Maybe put it in its own file(s). The idea is to make it a black box.
I can still remember the last time I did that with code to handle a clipboard paste on a server running in an RDP session. Five years on and no one has touched that code since!
Speaking of documentation…
From day one, keep a file — preferably encrypted — with all your notes, passwords, etc.
In all three jobs, on my first day there as soon as I had my computer and login, I started taking and keeping searchable notes and kept them in a backed-up area (OneDrive, Dropbox etc). Microsoft OneNote has AES encryption, making it handy for passwords, payroll logins etc. but before that I used single-file Wikis.
In any job, there’s usually a mass of information you need to absorb. Names of servers, email addresses, locations of source files on servers, passwords and paths for VCS etc. After eight years in my current job, my OneNote file has grown to 36 pages of information. I still use a pen and notebook for day-to-day work, but it would be much harder without my OneNote file.
If your company doesn’t use one, encourage setting up a Wiki for team related information. At my current job we use Confluence, a sister product to Jira and each team has its own work area. With documentation and resource files scattered across several folders on a server, it’s useful to keep the locations on one or two Confluence pages.
Since we started using Teams five years ago, some information was kept on chat info tabs — Teams is definitely not the best environment for that. Using chat pages means anything useful gets lost in a few hours, search is barely adequate and having information in multiple places is not helpful.
Some minor tips
- Create a reasonably strong password and add a two- or three-digit number on the end. When it’s time to change it, just increment the number.
- On Windows, install the freeware tool Everything from voidtools, it makes finding large files or duplicates quick and easy, and is the best file finder I’ve ever used.
The tools change. The rest of it doesn't. Keep your notes, protect your sprints and write for the next person.
