I began my 'career' as a software developer 30ish years ago by hacking around on a 8086 PC running DOS 3.something. I say career, but in reality it is just something I enjoy doing and get paid for. Over the years I have upgraded, migrated, scaled and refactored my skills such that I feel reasonably confident tackling pretty much anything on a PC or smaller (just don't expect me to always like it :).
Similarly the environment I work in and the way I work has also changed. I started alone, was self employed, then not, joined teams, led teams, hired people and fired people, worked on projects, worked as a consultant, worked on products and now I'm back to working alone. I've also tried, failed and succeeded at waterfall, RUP (big fail) and variants of agile.
Client/server came and went and came back again (arguably). Clients got fat, then thin and now they are fat again. Disks got bigger, then smaller and bigger at the same time. RAM got cheaper (anyone remember $100/MB?). Software got harder. Users ? ... they didn't change.
I have come to realise that the current product I'm working on combines the sum of most of this experience and I'm actually very comfortable working alone. Initially I struggled with not having others to bombard with tedious stupid questions, but over the last 3 months I have re-learned self-reliance and improved my problem solving skills (albeit with a little help from Google).
So, this morning it dawned on me that it is still possible for 1 human to churn out some pretty complex and modern applications. There is some value in documenting this for me, but also hopefully for others. My observations follow.
Decision making is easy
There are no meetings, no designs, no clients. Just a goal and a path to follow. Sure, there are side tracks and shortcuts but it's all up to me. I can wend my way as I see fit.
Tick for OHB.
Deadlines are arbitrary
I have deadlines, but only around how much time (and consequently $$$) I can afford to spend on this project. Living off my savings here in Thailand is a lot more possible than in NZ. So I can work on anything I like but I'm not doing any other work so I can spend 0 or 24 hours a day coding if I choose. Occasional trips to the ocean for diving etc are ok - have notebook, will code.
Tick for OHB.
It's fun again
All projects have good parts and bad parts (curate's egg). For example, creating CRUD data layers is boring rather than bad but I can twiddle with some Typescript front-end or do a blog post when the boredom gets too much. I'm free to mix and match as much as I like.
Tick for OHB.
Free is good
Not having a deep-pocketed-employer means I have to resource myself. Back in the day, $25 floppy disks from a Singaporian supplier provided all the software I needed (statute of limitation has expired I hope :). These days there is so much free and super cheap things available, keeping up to date is the problem. Even accessing cloud platforms is cheap (ie, I've created a cloud platform for test and prod based on skills I learned from my previous employer for about $50 per month).
Tick another one for OHB.
While documentation is mostly pointless for my own sake, there's always that Big Red Bus that can get you. Protecting your assets (and ass) is a good idea. You need backup - weather it be paper, bits or flesh.
Cross for OHB?
You can do what you like but you have to do it all
There's enough to do to on this product to spin off to 3 devs, a designer and a tester. I also get easily distracted by the latest twitter storm or Trump dumpster fire. Things would also go a little quicker at times if I had someone to help.
Some discipline is useful. I've learned to focus and finish things but the backlog is full of V2 ideas. I like to think that PRAGMATISM is one of my best skills.
Cross for OHB
Strictly speaking, I'm not actually alone. This product is a redevelopment of a product for a friend who is also a OHB. Somehow he manages to run multiple businesses and a family and still find time to do some programming. He's been doing this a lot longer than me so I know it's still possible. All I need to worry about is writing about a million lines of code.
In summary, here are some tips for prospective OHB's:
- Learn to cut - don't over engineer!
- Create a backlog and use it.
- Don't worry about too much tech (see below). Velocity is better than completeness or industry correctness.
- Your way is 'best practice'. Yuk, I hate that phrase but essentially if it works for you, it's right. Don't change just cause someone says you're doing it wrong. There's needs to be a better reason to change than peer pressure.
- Take a break. Give your brain time to relax. Do something none-codie for a while. Go diving. Enjoy the oceans while we still have them. It's awesome.
- Have fun. If you're not enjoying it then you're better off working for the man and getting paid at the end of the week.
More technically speaking:
- Script as much as you can but don't be afraid of manual tasks. I've scripted my AWS deployment using Terraform which is great now that it's done but it took way too long to do. It would have been better to do this later after I had a working product.
- DON'T performance tune too soon. You'll get bogged down in things that may not matter.
- DON'T get caught up in semantics. Unit testing, system testing, integration testing, blah blah blah testing. Just test shit. Call it what you like.
- DON'T be afraid of new things but stick with tried and true. I had to choose between SQL server and DynamoDB or some other No-SQL platform. In the end, SQL was just easier and there are parts that would be a LOT harder without it (clever of you Microsoft, very clever).
- DON'T use a build server. You can create a build environment in Docker and not have to worry about the time and expense of setting up a complex beast.
- Avoid the shiny but keep up to date. Once you release it's a lot harder to update your frameworks and libraries to the latest version. It's better to keep up to date while you're deep in the code. It's nye on impossible to stay up to date when you have over 200 front-end packages, but do your best.
- If you see something broken, fix it right away. Fixing bugs is very satisfying and you may also find there is some deeper fundamental problem - if you keep building on top of that, there will be a bigger problems later.
- DO USE GIT. I spent 4.5 years hating git. Now, not so much. It only gets complex if you get complex, so..
- Above all else, keep it simple!