thoughts

A flock of sheep in a green grass field. The sheep are a bit dirty, but all looking at you.

Do engineers dream of endless complexity and problems in their sleep?

Yes, it is a “funny” word play on the legendary sci-fi novel Do Androids Dream of Electric Sheep? The title of this article is something I have had in the back of my mind since very early on in my career and it has stuck with me.

Note! If you are offended by swearing, bad language and grammar you will have a blast reading this article as it contains a lot of it 😂

🌟Green field projects

The bare mention of the word makes people have a certain glow in their eyes and can almost see their pulses rise. It’s that mythical thing that you have heard about while making your way through an endless maze of legacy code written by what has to be some programming illiterate that came before you.

It is you chance to Make Things The Right Way. You have dreamt of this moment for so long and now finally you are to be part of such a project.

The architecture diagram is a blank canvas. You have heard the phrase “we will use the best tool for the job on this one” uttered by managers. Deep inside you know this will be great.

Let’s gooooo! 🏎

There is a project kick-off and everyone is super excited. Everyone has been reading up on what is The Latest thing to be using. The room (virtual or physical, it doesn’t matter) is buzzing and spirits run high.

Designers, product manager and programmers alike have all arrived at the promised land together and it just feels amazing. This time, we know We Will Get It Right.

Fast forward, the project might be in an ok or it is in deep 💩. The outcome is not what I will be talking about here, it is rather the completely irrational way in which we go about setting up Something New.

Three steps for f**ng things up when starting something new

Pick technology based on what looks good on your resume and your personal preferences
Make sure you are ready for scale from the first moment
Focus on ensuring the programmers are enjoying themselves

CV Driven Development vs “WE ARE SO F**KED” Driven Development

CV Drive Development (CVDD) is a thing, heck I’ve practiced it for years early on in my career. Why wouldn’t you? If you work on dead-end technology, that means you career is heading in the same direction. Naturally we have a tendency to gravitate towards what makes us look good.

In a green field project, you absolutely have to have a grinch onboard. Someone to ensure that the team are not going completely ape-shit in the candy store just because they can.

A green field project should be treated as a startup, meaning you have zero money. It should’ve been done yesterday and investors are on your case to shut you down. That makes for a _great_ climate to make technology decisions. Why you say? Because it means you have to be honest and focused. No more CDD or reading blog posts about The Latest Thing. It’s about shipping value so you’re not shut down tomorrow. Most people would then choose Boring Technology. You choose something that you know, something that will give you velocity from day one and that is simple to work with.

Google Scale Baby 🚀

A project manager or some stakeholder early on in the projects would usually layout the possible future. How this project will be a game change and that it will be critical for the business ability to grow in the future. It is intended to inspire and rally the troops.

Again, this is where you need a Project Grinch on hand. We all pretend we know about premature optimization, but let’s be honest we mostly use that as an excuse to skip things like testing, performance and security considerations 🤷🏼‍♂️ In reality, since this is a Green Field Project, we secretly are already at Google Scale.

We choose tools, frameworks and technology platforms which are often times months if not years in the future. Let’s face it you don’t need to setup a Kubernetes Cluster and create your own Development Platform from day one. In fact what you could do is to host the damn app on an iPhone 8. Because: YOU HAVE NO USERS!

Our Inner Engineer just can’t be silenced. We so desperatley want to do “what the big boys are doing” that we just can’t wait to get there. Which is why, especially on green field projects, we just go all out over doing everything. Be it the git repo structure & the pull request regime or the runtime platform you choose.

Green Field projects very quickly become the new legacy because we are not thinking about the context we are in. We are not considering what are the things required for the things right in front of us.

Developer Experience

The phrase has been abused by so many people with such a variety of agendas that I feel the meaning of the word is gone years ago. It is also a term hailed by Propper Engineers as the ultimate goal of any software development organization. If this is not your #1 priority, you are doomed. DOOOMED! As the art of typing instructions for the computer to run is The Most Important Thing. In reality it is never the most important thing, as it is always the business which is important. If that is not on track an amazing developer experience don’t get you anywhere but a new job for the engineers.

The Project Grinch would say: “Oh really?”. In order to ship value there has to be an effective way to get things in front of customers / users. I am not debating this fact. What I am sure of is that this should not be the ultimate goal to have ready from month one. I would say it doesn’t need to be there for years 1 or 2 either. Again, in a Green Field project, we have a tendency to just loose it on this point. Because FINALLY we can set it up just right. We can have the quick builds, with the automated tests. End-to-end tests and integration tests. Feature environments for all branches. Database migrations with rollback. EVERY DAMN THING!

The task of writing the code is so precious and whatever small obstacle preventing us from doing this has to be eliminated. Preferably with something shiny and nice. Whatever the actual cost and whatever the increase in complexity, it needs to be done. Let’s do a mono-repo and then when that starts to hurt we will just add more technology on top of it. Something like NX (in the JS eco system) which sounds brilliant. We throw all the shiny tools in to remove ANY hints of friction to the sacred art of writing code (completely ignoring the added complexity that goes with removing said friction both short and long term).

Don’t get me wrong, having all this in place already _could_ be useful. However all these things also come at a cost which you might not want in an early stage project. Let’s say you have a feature environment setup ready, so why not Just Use It? Well, it might be that this setup requires you to do feature branches. Which effectively makes everything related to continuously delivering value to users harder (yes, I know you _can_ do CI/CD with feature branches too. What I am saying is that you probably should not).

A different approach would be to say: “scrap that, let’s do trunk based development“. You reduce the complexity in getting things shipped and you a healthy mindset of getting things out.

How to not fuck up

Ensure you always have someone who has no stake in having shiny technology on their resume
Ensure you have someone who knows that any projects success hinges on the business side of things first and foremost
Ensure you have someone on the project to tell the Engineers to “stop f**ing about”

You are welcome 🙇

Chains in the foreground and a setting sun in the background

On praise in the workplace

You were forced to work a lot to reach a milestone set by someone else. It could be for a number of reasons and often times it’s because someone made a mistake that these things happen (or the person in charge is an ass or an incompetent ass). You put all things on hold, dig in and put in the hours. Depending on how long this lasts , days, weeks or even months. Your physical and mental health starts deteriorating.
Your reward? Some mention on Slack. Pat on the back. Honorable mention in the weekly update. You get everything except compensation for your sacrifice. It is natural to feel a sense of joy and gratitude when seeing this, but you should not as it most like means you have been taken advantage or.

You ended up getting the short end of the stick here. In exchange for your own heath you got praise (while it should have been praise minus the p). Whoever needed you to perform this transaction most likely got a bigger reward. If it was a bad sell, often times the sales person still got their pay.

There are of course potential upsides in you becoming noticed, perhaps even getting promoted or receiving a raise down the line. You will get the appreciation of your peers, which is nice.

What you will not get is time to heal. Time to catch up on the things in your life that was sacrificed. Time to recover physically from the toll it took (some places you get time off to compensate for overtime, others not).

When you receive that praise. Don’t mistake that as a reward, it’s the documentation that you got the worse part of a deal someone else profited off of. You should not be happy, but angry. Your learnings should be: Never Again!

Wage labour is the transaction of someone renting your body in exchange for you applying your knowledge. When forced (and forced here could mean peer pressure, “the company’s future is at stake”, etc) to sacrifice more of you without actual real compensation you are giving away parts of you for free.

It is on the privileged to make the change happen

Yes, this is not quite that simple when the employer holds your families faith in their hands. When your stay in a country depends on your employment. If your income is used to support family and loved ones who can’t work. There are so many thing which makes this difficult.

The people I’m addressing with this post are the people with the privileges. We are the ones who can stand up and help others not have to do this deal with the devil.

We have little / nothing to loose and we should work hard against cultures of hollow compensation for heroics.

Colorful wires going into a circuit board.

On reducing complexity

This is a common challenge once a company has built enough “stuff”. The burden of maintenance and the difficulties in refactoring makes one cry out for “Simplicity, now!’. A common perception of reducing complexity is to “dumb things down”, this is a reaction to the tension of it being difficult to untangle things. It’s often a good idea not to act on this tension, but look a bit further at the issue at hand.

Before even starting to consider doing anything, it is worth while to take a step back and analyse what exactly is complexity. People working together sometimes create established truths and create a shared understanding of how things are. Not based on research or analysis. There are multiple forces at play when a team starts talking about “too much complexity”. It can be a failure to deliver on their promises leading to a sense of failure and a need to place blame outside themselves. In companies with a hierarchy teams often create a lore of complexity as an explanation of why things are not going as planned. In the post The hidden meaning of complexity in the context of software development I talk about how the word complexity can mean something different entirely.

How to go about changing things?

One way to reduce complexity is to have to deal with less. Are there parts of the application which hardly ever changes? Would it make sense to split out isolated behavior from the main build? When doing this you can often get the counter argument of “we don’t want micro services!”. True, splitting out into separate might reduce some complexity and focused services that hardly gets deployed are great! However you can also isolate code which hardly change into libraries you compile in, reducing the number of things to build.

The misconception of thinking that reducing complexity always means removing or reducing things. You might actually reduce complexity by embracing new paradigms and undertake larger changes in your architecture. Doing this might require you to acquire new capabilities and learn new things, however this is not the same as adding complexity. Learning and evolving is always a key part of software development and should be just as natural to do when trying to reduce complexity.

Let’s say you have monolithic API which has grown out of control with long build times and a lack of efficient horizontal scaling, one way of reducing complexity could be to make drastic changes. Perhaps you need to insert a message queue and embrace an event based architecture? This might seem counter intuitive to reducing complexity , as setting this up is not that simple. However I would argue that often is this planned complexity preferable to the accidental complexity of a module which has grown out of control.

The means of production

When rescuing complexity an essential task is to look at the means of production, which is software is the delivery- and runtime infrastructure. Whatever path you choose in order to reduce complexity, it has to start here. If you continuous delivery system is fragile, or non existing, that is a place to start. If your infrastructure isn’t possible to replicate without manual procedures, that’s a thing to fix.

The reason for this is simple, no matter what you’re looking at doing it’ll be a nightmare if these things aren’t running smoothly. It will greatly reduce the types of things you can choose to do and it will also increase the time it will take to dig you out of the hole you are in.

Blocks with letters on them spread out over a table.

On words

I had read the term many times on the Internet from people who’s been vocal on certain topics which for different reasons turn out to be controversial.

Gaslighting
https://en.wikipedia.org/wiki/Gaslighting

I encountered this term for the first time when I was being vocal about an IT conference in Norway which I thoughts had a highly inappropriate name (post in 🇳🇴 Den Norske Dataforening sitt manglende gangsyn) . During this action in trying to get them to change, I was exposed to this behavior for the first time.

When I say first time, that’s a guess, as before this happened I didn’t know there was a word for this. Luckily I had someone by my side who, sadly, had a lot of experience in these sort of things. She helped me develop a vocabulary for what was going on. I didn’t know what it was, just that the situation was very uncomfortable and I didn’t know what to do. Without the guidance and help from someone who had words to describe what was going on I would have been lost and probably made a lot of mistakes and failed to grasp the situation.

Having experienced the meaning of this word, gaslighting, I took it seriously and started reading and digging deeper on this topic of manipulation. Slowly developing a vocabulary and a frame of reference for which to interpret what had happened. This work has been very valuable when I have found myself in similar situations, lost without the words to help me describe what I was experiencing at the time. The technique of gaslighting is not just something which happens during discussions on the Internet. Once you become aware of it you will see it in public discourse and also in your own work place. Using your knowledge, on subjects such as this one, to help others better understand their situation becomes a natural thing. You want them to be empowered to find the best way for them to deal with their situations.

Improved communication with a larger vocabulary

The power of words also applies to the art of engineering. One of the things you will notice as you have spent years in this industry is that your vocabulary grows as you go along. You can choose to use this power for good, such as improve the quality of communication. However, there are also ways to use this newfound power to alienate and put up gates preventing others from participating. It is entirely up to you how you use the power of words.

I remember being introduced to the concept of refactoring early in my career. It was mind blowing at the time as up until that time I would just change things and make random improvements. Going about changing my code using a vocabulary others could relate to and understand helped improve the quality on conversations about code. The word refactoring has been deluded to mean “change random stuff”, however it was defined as this:

Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each refactoring, reducing the chances that a system can get seriously broken during the restructuring.
https://refactoring.com/

By using the terms and words outlined it enables effective and clear communication to those who share this vocabulary. It means you can spend less time describing the intent and the objective outcome, as it is implicit in the name of the refactoring. A senior developer would use this language, but in the presence of less experienced people they would take the learning opportunity to help them learn the words and their meaning. To use the power of words as a tool for education rather than gatekeeping is essentially what separates a mature developer from someone who is in it for their own benefit only.

In closing

Words carry meaning, power and the ability for you to easier grasp your current situation. Establishing a vocabulary is an essential part towards learning more about something. This is the same in all walks of life. Acquiring the words to best describe things within a domain enables you to gain a broader and deeper understanding. It is the first step enabling you to learn more.

Hand holding a white cup with the text "The adventure begins" with a lake and a forrest in the background.

Hvordan forberede deg til neste tur?

Jeg har tidligere skrevet om hvordan du kan se på karrieren din i “Pakk sekken med ting du trenger for turen”. Denne gangen skriver jeg om noe litt annet, nemlig hva du kan gjøre for å komme igang med å planlegge din neste tur i karrieren din. Det er mange ting jeg kan og enda flere jeg ikke kan, men er det noe jeg har dokumentert kompetanse på så er det å flytte meg i arbeidsmarkedet (bare sjekk profilen min om du ikke tror meg). Likevel er jeg kun spesialist på min egen karriere så alt du leser må du selv finne ut hvordan passer deg.

Lag pakkeliste

Alle som skal på tur som skal vare litt trenger å lage en pakkeliste over hva du trenger for turen. Denne pakkelisten er vanskeligere å lage jo lengre du har vært i en jobb. Det er lett å tenke at etter fem, ti eller femten år i samme bedrift så kan en ingenting som er nyttig noe annet sted. Ting du gjør hver dag føles trivielle og enkle. Situasjonene du har vært i, problemene du har løst flere ganger virker enkle og ikke spesielt interessante.

Det som er lett å glemme er at ikke alle steder er som der du jobber. Veldig mange steder har utfordringer nettopp du kan løse. Problemer du har løst et utall ganger er noe de mangler kompetanse til å løse. Ingen steder er perfekte og alle steder har utfordringer. Sjansen for at du etter lang tid i et selskap har noe å tilby vil jeg si er rundt nittiåtte prosent. Ikke undervurder hva du har lært og ikke ta forgitt at alle andre er så fantastiske som det de fremstiller det. Alle jobber og selskaper har sine problemer og gjør sine idiotiske ting. Derfor trenger du ikke være engstelig for om du har noe å tilby, selvsagt har du det. Ingen som har jobbet i fem til ti år er ubrukelige, så ta deg tid og ikke være kritisk når du skal skrive opp pakkelista. Pakkelista inneholder utfordringene du har møtt på, problemene du har løst, situasjonene du har stått i og kommet ut av. Det er tingene som gjør at neste turen din går lettere. Den sekken du har med deg er veldig mye tyngre enn du først tror.

Photo by Julentto Photography on Unsplash

Planlegg turen

Å se på karrieren som en tur, enn som en stige, er befriende på veldig mange måter. Det har derimot den baksiden at du faktisk må planlegge mer når du ikke bare skal oppover en stige. På samme måte som når du skal legge ut på små eller store ekspedisjoner så trenger du planlegge i forveien. Du trenger ikke en ferdig lagt rute som inneholder detaljer som tider, datoer, m.m. Derimot kan det være lurt å ta tida til å reflektere kanskje en gang i kvartalet for å se hvor du er. Lærer du noe? Er det noen andre arbeidsoppgaver som frister mer? Er du frustrert over at du ikke får brukt det du kan eller vist deg fra din beste side? Trenger du mere penger for å få hjulene til å gå rundt? Avhengig av hva du kommer fram til, så kan det hende du trenger å legge inn litt tid til å planlegge hvor turen går videre. Hvilke ting ser du etter i en ny jobb? Er det arbeidsoppgavene du vil endre? Ønsker du å utforske et nytt fagfelt? Trenger du bare miljøskifte? Savner du å jobbe i et internasjonalt miljø? Noter ned hva du ønsker, for det vil hjelpe deg finne veien videre.

I det du har tenkt tanken om at turen kanskje går et litt annet sted enn den er på vei nå, så er det bare å begynne å planlegge. Ikke vent, for i det du har tenkt tanken er alt annet bare instinktet om å søke komfort som slår inn. Start planleggingen med å oppdatere LinkedIn profilen, begynn å følge med på annonser på steder hvor du tror en potensiell arbeidsgiver kan finnes? Kanskje trenger du å snakke med en gammel kollega? Ta en kaffe med noen du har likt å jobbe med? Søk litt impulser og se hva som trigger deg. Planleggingen vil ta tid og jobbsøking kan være ganske mye jobb om du ikke har en plan for hva du vil.

Du trenger ikke gå på tur alene

“Hva med alle de gode kollegaene?” spør veldig mange når jeg nevner det med jobbytte. Jo, jeg har hatt veldig mange gode kolleger og noen av dem er mine venner fremdeles (jeg har skrevet om dette i “Du får ikke venner på jobb”). Men, tingen er at det finnes veldig mange som venter på å bli din neste gode kollega. Selv om stedet du jobber nå føles spesielt, så kan jeg med min erfaring si at det finnes mange spesielle steder. Det er ingen grunn til å tro at du ikke vil få gode kolleger andre steder. Du trenger selvsagt å finne ut om et nytt sted vil gi deg nye turkamerater som du har lyst å være med, men sjansen for at det finnes noen er i følge mine beregninger rundt 80%.

Du angrer aldri for at du gikk på tur

Det eneste som er sikkert er at du aldri vil angre på at du bytter. Uansett hvordan det går, så vil du ha lært masse bare av prosessen med å bytte jobb. Du har fått klarhet i hva du ønsker og ikke ønsker i en ny tur. Gjennom intervjuer og prosesser lærer du nye selskap å kjenne og lærer ting om deg selv. Kanskje gjør du et feil valg, men det er jo ingen katastrofe (slik dagens arbeidsmarked er vel å merke) fordi neste jobb er faktisk rett rundt hjørnet. Jeg har aldri jobbet noe sted så kort at jeg ikke har lært noe. Selv om jeg har vært med på en tur på bare noen måneder har jeg lært verdifulle ting som har gitt meg mye som person og gitt meg ny faglig kunnskap. I mine femten pluss jobb bytter har jeg aldri angret på at jeg tok sjansen på å legge ut på en ny tur. Uansett hvordan det har gått, så er jeg en erfaring rikere og kommer bedre ut av det enn om jeg ble værende.

Å bli værende fordi du føler lojalitet eller at du svikter jobben er en vanlig følelse. Spørsmålet er om du egentlig tilfører jobben noe særlig om du er der fordi du tror andre mener du burde? Lojaliteten bør ligge hos deg selv og de viktige personene i livet ditt. En arbeidsgiver er noen som betaler deg for at du skal gi dem din kunnskap, muskelkraft eller lignende. De vil aldri gå det lille ekstra for deg, derfor skal du heller ikke gi det tilbake. Du skylder deg selv å tenke på hva det beste er for deg. Fordi du fortjener det.