I thought I was going to write one of those listicles just to get going as I have posted nothing for half a year. Recent developments have made me take stock and figure out what certain people have taught me while working with them and what I should try and learn from them going forward. I will not cover the basics of TDD, vim vs Emacs, tab vs spaces or any of that. I will assume you write good tests and create largely correct, well structured code that your coworkers can understand clearly. I will just address things you can do right now – outside of the actual coding – to be the best you can be.
1. Go home at the end of the day
This isn’t a new lesson, but it is important to note again. Do not give the company any more of your time than you agreed when you signed on. You may love the company and the management, but you are not doing yourself any favours by spending too much time in the office. You may think you get more stuff done, but what I have learned is that you can get more done in 8 hours per day than most people do in 9 or 10, but it takes some hard work and focus. In the other points below I’ll try and identify some of the tricks these people use and see if I can perhaps pick up on those I’ve yet to implement myself.
Another reason I brought up this topic is that I have recently seen people fall into the trap of giving their life to the company. If you own equity and have a chance of a real upside that may be a trade-off worth making, but if you are a lowly employee, even if you have option rather than stock, it is highly unlikely that the arrangement is going to pay back time lost from seeing your family or even just resting to be fit-for-fight the next day. The company will never love you back – it cannot.
Even with equity, think about it – you wouldn’t cut an employee any slack that had worked themselves to the bone and after a while started making serious mistakes. Miss a client meeting due to oversleeping after an all-nighter in the office? Starting to create more bugs than they fix? Maybe started yo act bitterly in the office when interacting with coworkers due to the asymmetric workload this individual had voluntarily taken upon him- or herself? The problems and even the discord being sown in the workplace must eventually be addressed despite the employee having put in enormous hours for the company. I’m saying there is a way to overwork yourself out of a job, which probably nobody in the company wants to go through and as an employee it is bound to be a bitter experience.
So – given the potential productivity and longevity of people that stay within their normal hours and the fact that they get to go home and chill with the family – this is the course of action I recommend..
2. Prefer early mornings to evenings regarding extracurricular activities
This is something I could be better at, but starting out at 5am if you want to do something extra curricular such as blogging or trying out a new language or technology is extremely effective. It is exactly like going out for a run in that a) I haven’t done it very often, but often enough to know that b) the hard bit is just getting started, and c) it is fantastic as you do it and notice how much progress you are making.
3. Never leave a question unasked
When you hammer out details about a piece of code about to be written – never leave a question unaddressed. Sometimes people hang back and assume that all edge cases are handled and that there are no more loose ends.
- Do we have everybody here that we need to flesh out this story?
- What is the expected outcome of the feature?
- What is the expected input?
- How will we handle untrusted input?
- Security concerns?
- Usability?
- How do we present errors?
- Will the stakeholders present, yes I was serious about 1, accept a solution that allows us to write less code?
- What is the lowest level at which we can automatically test the acceptance criteria?
- How do we deploy the feature?
- How do we monitor it?
- Do we need to produce any additional deliverable (yes, docs, manuals)?
The biggest way you can save time and get to go home on time is by not making mistakes, and one way to not make mistakes is to know that you are building the right thing the first time. Not advocating a Big Design Up Front, just a Right-Sized Discussion Just In Time.
4. Be the one that takes notes at design meetings
After asking the right questions-volunteer to do the dirty work such as updating ticketing systems, to make sure none of the information you are just about to use to write code is lost on the way. Documentation is often a waste, but this bit – details about the acceptance criteria for the feature or bit of code you are about to write is actually useful for a while, at least until the code is in production later today or tomorrow.
5. Maintain standards in terms of tooling and infrastructure
Keep your house in order. Don’t have your development machine behind on patches, behind on OS versions, on old development tools or in a state where you and or a coworker cannot be immediately productive. I have struggled with this as I for a while as I recently out of stubbornness tried to run a Linux desktop in anger. I thought 2016 would be the year of the Linux desktop, and in a lot of ways it was. Debian feels very natural for a Windows user. For chef, Javascript, even some PowerShell I did fine and was productive. However since most of my work is in C# on .NET I had to employ all kinds of other ways of running Visual Studio on VMs, on a laptop, or wherever which was annoying to everybody. Thankfully once I lost patience, thanks to my efforts in scripting, I had new Windows environment running directly on the metal set up in hours.
Do not let broken builds stay broken. If tests are flaky- address that, either by replacing the tests with more robust ones, or remove them completely – but do put yourself in a position where any build failure is probably legitimate and is resolved immediately.
Constantly challenge the automation – do you need it? Is it over-engineered? Does it cover as much as it needs? Is it flexible or is it brittle?
6. Be helpful
Be ready to talk to anybody in the company that has questions about what you do. Pretend like you have boundless energy (which, to be fair you probably do since you now go home on time everyday). Even parts of the organisation that for historical reasons doesn’t have much faith in development/engineering (yes, that happens everywhere). Be there, answer stupid questions, insinuant questions and honest questions with a smile or at least a reasonable facsimile. Try and note down any specific complaints and welcome your critics to sit in when you elaborate stories regarding their favourite topic in the future. If you are prepared to do some internal promotion you will be trusted in the rest of the company and liked by your colleagues who probably avoid those people like the plague.
Don’t arm yourself with headphones and plug away leaving your more junior colleagues stranded if they ave any questions – the total productivity of the team isn’t helped by you being in the zone if at the same time three people are struggling with something that you could have spotted right away.If you really do need to be alone to solve something, book a meeting room or something, get out of the landscape/team room.
If a couple of people have questions about anything you are doing, offer to do a brown bag on it, send out invites and see what the traction is. If you create a culture of curiosity and willingness to learn the company will make money and everybody will appreciate your effforts. Myself I have known that these things are useful and peple find them interesting, but it is only the brownbags or lunch & learn sessions that actually get scheduled and actually happen that are beneficial, the ones you ponder quietly to yourself but never actually set up are worthless. Take action.
7. Interact with peers outside of your company
Now, this seems to fly in the face of that Go home at the end of the day-bit, but this benefits mostly you as a developer and only secondly your employer. There are meetups and user groups in loads of places and you should find some and go there. This is an item where I really need to improve. Especially if you are involved in a technology that is quickly evolving, such as the language Elixir has been over the last couple of years, swapping war stories to the extent your NDAs will allow can be quite useful. Any piece of new discovery that you can share can benefit the local community and in turn you can have some of your queries addressed. It is a very good way to figure out how much of advertised technologies actually get used, and in what way and can thus help you correctly judge what new technologies are worth looking into to solve business problems at work.
Right, so for this listicle n appears to equal seven. Do you have any more traits of successful developers you have noticed that you would recommend, or just stuff that you do that is awesome and that we all are fools if we don’t emulate right now? Feel free to share.