I recently transitioned into a full-stack role – I wanted to stretch myself and step out of my comfort zone. The biggest challenge was my struggle to quell the quite nagging voice in my mind screaming ‘impostor!’.
So I got a couple of Big Hairy Audacious Software (BHAS) pieces dropped on my plate and that experience motivated this post; after all who doesn’t want to get better at delivering BHAS projects? My style of working is to consciously take notes as I run into issues, ship software pieces or meet milestones. The introspection typically involves 3 questions:
- What to avoid:
While shipping some feature, I implemented some shared parts in the common library. Unfortunately, that caused a lot of dependencies and significantly slowed down my development speed. Learning? Implement the shared pieces in the same library and do the refactoring as a follow up task.
- What to repeat
Typically hard-earned lessons, for example, having to debug issues in production quickly showed me what good tracing information should look like.
- What to improve
The middle ground, things that went well but could be improved. This is mostly driven by notes I keep while developing.
So thoughts so far.
1. Define the end goal
A BHAS project contains a lot of ambiguity in addition to the technical challenges involved! A sample task might be to implement a usage tracking system for ships.
The first question should not be ‘how do I start’ or ‘where do I start from’; rather I’d re-frame that to be ‘What is the desired end product’; what does a successful launch mean? Having crisp targets and communicating those to all the stakeholders is very essential as it helps to set the right expectations.
Furthermore, once the success metric is known, then it becomes possible to breakdown the BHAS into smaller more manageable chunks with less ambiguity. Once done, order this list and put the tasks with the highest impact at the very top; why? The Pareto principle (also the 80/20 rule) implies that a few of these tasks would provide the highest importance and value. So if you don’t get the lower tasks done, it’s still a win.
2. Take small measured steps
A favorite quote of mine:
How do you eat an elephant? One bite at a time!
Assuming you picked up the most important task to work on and are still stumped. Start with the simplest easiest thing you think will help you wrap up that task – it could even be creating a branch or implementing some simple helper function.
Why this is important is that it sets you on a roll and helps you to build momentum. The more micro-tasks you complete, the more confident you are and the faster you accelerate towards ‘cruise speed’ (aka flow).
3. One thing at a time
I have tried in the past to multi-task; on such days I would feel like I did a lot of work yet deeper examinations would imply low productivity. There are two theories that come to mind:
- My brain convinces me that rapidly switching is more efficient and productive.
- Same brain convinces me that it is possible to simultaneously do two mentally intensive tasks.
No, humans can’t multi-task; rather our brains do rapid context switching. So if you think you can carry out two very demanding tasks then you either have two brains or are losing ‘brain cycles’ to rapid switches.
Another illusion to watch out for is the effect that confuses ‘busy work’ with being ‘productive’; no you can be busy (answering emails or chatting etc) without being productive. Now, I try to do one thing at a time with full mindfulness and the results have been more meaningful outcomes.
So if you are working on a task, concentrate all efforts into finishing that task alone. When you are done or if you get blocked, then you can consider jumping on a parallel or orthogonal task.
Staying mindful is also quite difficult as there are lots of distractions – consciously evaluate if you need to be in that meeting, that discussion or reply to that group email.
4. Be persistent
Once you’ve picked a task you should stick to it. Ideally any task you are working on at any time should be the one with the highest projected value returns (think weighted graphs).
Sure there might be difficulties but instead of skipping around you should dig in and solve the challenges. Ever wondered why you only get the urge to check email only when a tricky question comes up? Aha, it’s the brain trying to ‘run’ away. Don’t check that mail – your brain is just seeking a way out. Give it all your best and push until you get a breakthrough.
5. Don’t seek perfection and ship the first rough version
No writing is perfect in the first draft; rather you get your thoughts out and then do a number of passes: cleaning up typos, grammatical structure and style in follow up sweeps. The same concept applies to writing code too.
I remember trying to beautify my code and write loads of redundant unit tests while building a particularly tricky interface. I wanted the first version to be perfect. Know what? Most of those unit tests got deleted when the feature was completed.
If you are trying to build a prototype to test how something works, it is ok to be loose with rules since it’s going to be a proof-of-concept. Once you have that done, you can then design the system, implement it and add tests.
I hope these help you to deliver better software more efficiently and faster. Again, this can be summarized in the following points:
- Define what the finished product is
- Break it down into chunks
- Ruthlessly focus on delivering the high-impact tasks – don’t multitask!
- Deliver fast, eliminate all distractions.
Do let me know your thoughts.