10 Things I Learned From My Latest Project That Aren’t All PC — Programmatically Correct

I’ve been a developer for about 2 years now. The funny thing is I have always taken what it means to be a developer for granted. I never sat down and thought to myself a developer is…?

I bet you didn’t think this is a what a developer is, but that is in fact a developer in the wild — that’s the cave man version of me :P

I pose the following question:

What is the purpose of a developer? -> I encourage you to ponder this a bit

While you’re pondering I’ll give you my thought — well actually the thought of Dan North which I came across in this video.

The purpose of a developer is to create BUSINESS IMPACT.

Hearing this completely blew my mind because I always thought implicitly that a developer writes code and creates software. This is true but the reason we write code and create software is so that it can create business impact — hopefully positive impact.

When I started on the project I reference in this post I hadn’t had this epiphany, unfortunately. However, I think revisiting the project with what I learned through the lense of creating business impact is quite valuable.

Some quick facts about the project before we get into it:

1. We inherited this project from another dev house (Oh no)
2. It was a 3 month contract where we had told the client that it would probably take 6 months to complete all the tasks asked for (suckers for punishment)
3. There was a CMS built in Laravel, a mobile app built using Ionic/Angular and AWS infrastructure, all with no documentation. (is it starting to sound fun yet?)
4. The two devs on this team (my colleague and myself) had never used Laravel, Ionic/Angular or the AWS resources used in this project. (basically the blind leading the blind)

With that in mind here are the 10 lessons I learned during my project:

WARNING: Some of these may not be PC

1. Don’t be a hero

Me trying to be a hero

When I first started learning about being a craftsman of programming all I wanted to do was make things beautiful, modular, clean etc…

As time has gone on I’ve realized that sometimes it’s:

1. Impossible to make an entire code base clean with limited time
2. It’s not always worth it to clean a code base (remember business impact, sometimes if it works that’s all that is needed)
3. Refactoring can take you down a dark path, where you end up with nothing to show for (like when things are too intermingled and refactoring it would actually take the entire 3 months of the project to do)
4. Clients don’t give a shit about clean code or tests or how the code base makes sense or doesn’t

Therefore my recommendation would be to underpromise and over deliver.

2. Code is? … COST

A big realization that Dan North enlightened me to is that code is a cost. Why do I say this?

The more code you have the more:

1. You need to maintain
2. Errors are likely to creep in
3. Difficult it is to reason about what is going on
4. Developers you need to hire
5. Documentation is required
6. Painful an architectural mistake can become

You could probably think of more but I think that makes my point. Again the aim of a developer is not to write code, it’s to provide business impact and sometimes that means not adding anything or taking code out.

3. Sometimes you need to get dirty

This point is why I had the earlier PC warning.

Dirty but content :) — Photo by Laura Anderson on Unsplash

The big lesson I learned on this project is that sometimes a codebase is dirty AF. You are literally swimming in the shit. All you want is for Robert Martin to magically appear and do a deep cleansing session so you can be magically transported to the euphoric feeling that is having a clean codebase.

BUT this is the real world. Uncle Bob doesn’t even know your name!

Therefore I say:

1. Become comfortable in the dirt that has now become your codebase.
2. Do the quick fixes you know aren’t perfect but would take 1 month to fix properly
3. Say no to refactoring the 1000 line file you only need to do a copy change in
4. And finally, learn to sleep well at night knowing that this will likely come back to bite you or some other poor developer in the future

OBVIOUSLY, I only mean to do this because you have finite time and sometimes a client needs a working (not necessarily a clean) codebase to pitch their product to investors, or get the first clients into the door or do some demo etc…

4. Steal from seniors

This is probably the most important lesson I’ve learned throughout my programming journey.

The reason being that when you sit down and pair program with someone more senior then you will most likely:

1. Solve the problem
2. Learn a new approach to solving this particular problem
3. A more efficient solution
4. A truckload of things you never thought you needed to know
5. Gain a much deeper understanding of the actual problem and why the solution being implemented is the optimal one
6. Shortcuts and extensions you can use in the IDE (I know I’ve learned about at least 5 extensions from pairing)

Jon a.ka. the Picasso of programming on a Picasso painting

This is a picture of a senior developer at NONA called Jon, over a Picasso painting. The reason for this is because I believe he is quite literally the Picasso of programming. Now why is this relevant, you ask? The following quote is why:

“Good artists copy, great artists steal”

P.S. Thanks Jon :P!

5. ASSUME makes an ASS of u and ME

Richard, a colleague of mine, said this in jest and it’s stuck with me since.

Making an assumptions is a trap that I think everyone falls for.

• The reason this feature is here is obviously because the client wants it…
• This deployment script is convoluted because it needs to be like that…
• There are for loops in for loops because this is the only way to do it…
• They used this technology because it was the right choice for the job…

And the reality usually is something more like this:

• After asking the client she explained that she had no idea why the previous dev house added that feature (this is a true story on this project and it actually occurred multiple times)
• He explained that he actually just made it work and didn’t have time to optimize it or clean it up, the previous developer who worked on the deployment script explained
• The for loops in for loops are actually completely unnecessary and should be broken up the old developer said after admitting it was a mistake she made when she was a less experienced developer
• The previous dev house actually used the technology they knew and hoped it worked for the project at hand

These things really happened in one form or another on the project so my advice would be don’t assume — question until you have a satisfactory answer.

6. What is the smallest thing I can do?

I worked on this project during lockdown. There were periods where I got quite depro and very overwhelmed by the project at hand. Whenever this happens I usually end up — actually YouTube recommends videos of him which is pretty amazing/ultra scary — booking an appointment with my favourite psychologist:

Jordan Peterson — famous psychologist

Now we’re not here to debate whether you like or agree with him or not (which is something everyone feels like they need to explain at the mere mention of his name -> Jordan Peterson = Instant “I’m not sure how I feel about him” response) but he does say a lot of life-changing stuff.

One example that helped me is an exercise he would go through with one of his patients who was depressed.

He told her to imagine her room. Then to identify all the things that she knew she could do but felt too overwhelmed to even attempt. After identifying the list of things he picked out the simplest task. Let’s say this happened to be to throw away the tissue that’s been on the table for the last few days. He asks her if she thinks she can do that? Of course she can and as they say the rest is history, HELLO BIN — GOODBYE TISSUE.

This resonated with me and I figured this could be applied to my project. Instead of thinking about the CMS, mobile app, tests failing, variables not making sense, code not being dry, …

I decided to break it down. What is the smallest change I can make that will improve this part of the project. Oh changing this variable name to something more sensible. Now I actually understand what this massive function is trying to do. Oh WAIT, I can actually break this up into smaller functions etc…

When in doubt, break it down! (Yes get on the floor and hit some crazy dance moves — that helps too :P)

7. Gingercake

Now this one I have stolen almost verbatim from Dan North’s talk (I’ve linked it with the exact place he speaks about this method, in case you’d rather here it from the horses mouth).

You have a chocolate cake recipe explaining the ingredients and instructions (NB! You don’t need to read into the recipe, it’s mainly for show unless you want to make a kick ass chocolate cake):

Then the person who created this recipe also gives you a ginger cake recipe:

Like a chocolate cake BUT with ginger

If you have ever attempted to make a ginger cake before you would know it’s nothing like a chocolate cake. Chocolate melts, while ginger stays airy among many other differences. The point of this though is that the person baking the chocolate cake knows exactly how to alter that recipe in order to create a ginger cake even though to the average joe this makes no sense.

This applied to me in the following way. I had implemented a form of redux (a state management tool) in a previous project and I understood how it worked quite intimately. On this project I needed to implement ngrx (angular’s flavour of redux) so I copied what I had done in the previous project and adjusted it to suit my new project. This saved me truck loads of time!

Now copying in general is not a good idea. Example I copied a a function from StackOverflow to solve a problem. It worked but eventually I was pairing with another colleague and we ended up needing to change something in the file. This function happened to have an if statement in it. He asked what the if statement was for and like a noob I had no idea. It turned out that the if statement was entirely unnecessary and may have caused issues in the future.

Therefore DONT just copy, only copy what you yourself have worked on before and adapt it to the situation at hand which implies needing a deep understanding of what you have copied.

8. Burn the boats

I hate to do this twice in a row but I am again stealing from Dan North, unfortunately I can’t seem to track down the talk I learned about this from.

There is a famous story I am sure you may be familiar with. Back in the day on a much younger earth the Spanish invaded South America. The generals in their wisdom decided that the troops needed a bit of a kick in the butt to get their heads focused on the task at end. The command to BURN THE BOATS was issued. Seeing that their only means of transport home had been destroyed the troops were left with a single option — colonize or die.

Now this may or may not have happened I am not sure but the basic precept of not giving yourself an option out is a very powerful tool. A tool that I used unintentionally in this project.

I was tasked with looking at the mobile app and unfortunately all it’s dependencies were massively out of date. They were so out of date that all the upgrade guides actually recommended restarting the project using the new versions and porting over the old app.

Me being the ever optimist thought this was a wonderful idea, and so began the porting over of the old app. This quickly turned into the rewrite of the old app and needless to say it wasn’t long until I was half way through the project and it was too late to turn back to the old app. My boats had been burned. Without an escape there was one option — FINISH THE APPN AT ALL COSTS!

Now I wasn’t fearing for my life but the pressure was definitely on and eventually it worked out (a lot of overtime and touch and go situations later).

I am not saying that this is the way to do things because I don’t believe it is. I was lucky that the mobile app was quite small to begin with and a rewrite wasn’t outrageously difficult, but I can say that leaving yourself no options is one way to get you focused and forced to get stuff done.

9. Time solves problems

Me looking into the distance hoping my problems will disappear … nope still gotta pay rent :P

This is a short one, but some problems go away if you wait.

1. Sometimes the client reprioritizes tasks after realizing it actually isn’t business critical
2. After rewriting the app and solving some deep rooted database issues a lot of the tasks we had we completed unintentionally by the fixes
3. “Desperation leads to innovation”, so you find out how to fix things quicker or more efficiently when you are running low on time *hopefully*

10. All that matters in the end — how it ends!

I’m currently watching The Last Dance, a documentary about the Chicago Bulls basketball dynasty with star player Michael Jordan, for the second time. One of the lessons I learned from the show is that it doesn’t matter if you win the MVP (Most Valuable Player) award, or you score the most points or block the most shots or assists etc… all that matters is CHAMPIONSHIPS.

Now unfortunately in software development we don’t have the NBA finals being streamed to millions worldwide but what we do have is a client. As you come to the end of the road on a project I always get the feeling that this is my version of the finals. It’s the time to shine. All the work, hours, mistakes, misunderstandings etc… either make or break the handover.

In our case success meant our client could go to market with her product. She didn’t care about the nervy demos, things crashing or not working for periods of time, that the database had been complete rewired or that the mobile app had been completely rewritten — all that mattered was that she could launch.

Luckily for us we put in the hard yards, prepared properly and managed to get over the line in the end. The product was launch-able — not perfect (what ever is?) but launch-able. We won our version of the NBA finals, and although millions weren’t the only person that mattered was ecstatic.

That’s why all that matters in the end is how it ends — and hopefully you delivered so you can hit the beach like this:

Me after completing a project successfully