Neon sign on a brick wall in a dark room which says: this is the sign you have been looking for

Three ways to successfully prevent your young company from succeeding 💪🏼🎉

I have been so fortunate as to be part of several young companies and starting new teams in existing organizations. This post is is a summary of my subjective observations, you should treat it as such.

1️⃣ Introduce departments too early

All young companies wants to grow up and become proper organizations. In order to get a head start, many young companies start splitting up their organizaiton into departments way too early in an attempt to look good for stakeholders and potential hires. “See, we know how to set up a business!”

The issues is that doing this when a company is just 10-12 people (I have experience this myself on more than one occasion) is setting your self up for problems you could avoid. With the introduction of constructs such as product, sales and operations you are creating boundaries and a need for synchronization. When you have a department, of course there needs to be someone running it. Hence you need to introduce a leader. Once you have three or more leaders, then there needs to leadership meetings, etc. What the company has been doing is creating the constructs which prevent larger companies from being efficient. Communication lines multiply, hand-overs and synchronization is introduced. You also formalize the tension which is between say sales and product.

I have been part of companies lulling themselves into the corporate mentality way before it is required (yes, it might be required at some point. However not when you are so few people). As we all know, the c-title people in young companies are usually the ones who where there first. Not necessarily the ones who’s best equipped to handle the role (I have first hand experience of this, I was CTO because I was the first hire!). You might need to have all kinds of titles and thing in your pitch deck to investors, but you should probably not actually have any of it in reality until there is a dire need of them. There is no going back once you introduce it.

2️⃣ Prematurely introducing processes & practices to scale

Software organizations are like crazed teenage fans when it comes to processes and tools. They blindly follow their idols without really taking the time to contemplate why. You will see small companies mimicing companies the aspire to become, as they think that is what has made the great. That is a grave mistake, as most unicorn or gazillion euro evaluated company probably did not start out with those processes. They needed to install certain processes because of any number of things. Maybe they grew into a thousand people company in two months. Perhaps they acquired a company in a different timezone. Someone gave them a truck load of money and they suddenly need to ramp up quickly. Or they have a total lack of trust in their organization and therefor install rigid processes.

Whatever the case may be, one of the key factors for rapidly growing small companies is their lack of these processes. It is a huge competitive advantage to not have to do the Spotify model (which is the go to model of choice the past years in my country Norway). Instead of trying to do what the big ones do, young companies should cherish and embrace the time when they don’t need any of it. It is the most fun you’ll probably have and the time you’ll be having the most creativity and being the most productive. Young companies should postpone installing processes as long as possible and most likely invent their own thing once they do.

The same thing goes for tools. There are certain tools which inevitably will make your organization less efficient (yes, I am talking about that product starting with Jir). Why does a 4 person development team need a bug tracker? If you only have the capacity to do two things in a cycle, do you really need a roadmap tool? I would say no. In my first startup we had a bug tracker, it was a sheet of paper which could only fill 10 bugs. If there where more, we’d either need to solve one or take one out. The sheet was visible for everyone (this was in ancient times when we used to go to things like The Office) and when it changed there was always a discussion about priorities. We did the same thing with items to do in a cycle. To date, this has been the best tools I have used to get work done in a small company.

The problem with task managers etc is that they put focus on the items, not on what value you want to create. Everyone gets focused on the individual work items and forgets about what it is that we bring of user value this cycle. The outcomes of each cycle becomes less important than completing the things we thought was a good idea when the cycle started.

3️⃣ Letting the engineers decide on their own

Three cubs on a mommy bear over a text box which says "solving imaginary scaling issues, at scale"
From https://twitter.com/thepracticaldev

You know what is going to happen when you let some engineers have free reign and build The Greatest Technology Platform Ever™ to propel your startup into the stratosphere. They will prematurely create something they think resemble what their idols do. It will be Planet Scale from day 4 for all of the companies 4 customers and 1 concurrent user. I would not say that this is a big exaggeration, I have seen it happen on many occasions. The enthusiasm to finally be able to architect the system they’ve envisioned all this time. To finally put into practice all the blog posts that they have read, all without really paying much attention to what the company actually needs in the beginning.

You should never let the engineers decide all things on their own, they need to articulate how it relates to where the business is right now and the next three months. There is no need for planet scale if you’re shut down in two months because you’re failing to get users. Opting for a serious cloud provider because “it will enable us to scale easily later” might be a decision which prevents you from shipping what you need right now and eventually kill the company.

Engineers should be allowed to choose many things, but they should not be doing it in a vacuum without close collaboration with everyone else. Prematurely architecting something complex has prevented companies from getting the chance to succeed more than on one occasion.

What should young companies do?

Woman setting with her back towards you with her back turend, watching beautiful sunset.
Photo by Sage Friedman on Unsplash

Take a deep breath, hold it for ten seconds and then exhale. Relax, put your shoulders down and instead try to enjoy what is the best time of a companies life. Rather than rushing into becoming a proper company, you should embrace the competitive advantage you have of not being such a company. The small size, lack of processes and hacky technology is the secret sauce unicorns are made of. They are not made up of practices from Google, Facebook, Amazon and Microsoft. If investors want structure, make a power point. Don’t mess up what potentially could be the best time!

Picture of a forrest with snow and a lot of branches everywhere

The hidden meaning of complexity in the context of software development

Complexity is on the one hand something which can be measured by tools to give an objective value of how complex something is. However, this is not how I’ve come to see the word used in my work as a software developers. In this article I will talk about some of the aspects tucked away in the concept labeled complexity.
It tends to be used to cover up subjective opinions or believes getting portrayed as objective observations. Being able to detect when this happens is an essential skill to ensure you are able to no loose your confidence in your own abilities.

Fear of the unknown 👻

Image of a dark hallway with lights coming out from two open doors leaving two strips of light in the image.
Photo by Kamil Feczko on Unsplash

In my early days as a developer I worked as a contractor on a project for a client where we where hired to get a project over the finish line. They where facing a deadline and needed some people in to product. This was a Microsoft based architecture and it was in the years just after ASP.NET was released. Upon entering the project we learned about the guiding principles by the clients own architect. What we hear left us a bit puzzled as the way in which we where expected to go about coding components and pages went against everything we thought was right. Essentially we had to write our web application as if we where stilling concatenating strings in Perl, but in C# on the .Net platform. We where only two fairly young programmers from our company at the time, but we both thought this looked funny.

We tried to advocate for ASP.NET actually being a productivity enhancement and something which could help us reach the milestones with less effort. Especially since what we where making was a booking calendar solution, which would be ideal for the built in calendar components in ASP.NET. We tried to advocate this and show how it would make things easer, more robust and reduce our time to market. The architect was having none of it. Presenting reasons such as performance and complexity for reasons to keep the current pattern of development.

In reality it turned out to be fear of loosing control and fear of the unknown which lead us to having to implement a solution which was far from ideal and which ended up consisting of way more code than was needed. Writing the calendar booking component in a “Perl-style” was in an objective analysis far more complex and added may more code paths to the solution than the one we presented using the ASP.NET controls. What was diguised as something too complex, was in reality something new and unknown for one individual.

More advanced does not always mean it is more complex

Knowing everything about all different software libraries and frameworks is really hard. Therefor it quite often happens that there are different levels of experience in a team. Developers who’s spent more time with a certain piece of software will know different patterns of how to solve certain things than the novice just learning it.
In cases like this the seasoned practitioner could be faced with their solutions being “too complex”. What the person uttering this often should have said is this: “I was not aware this was a way go about solving this problem. Could you please tell me more”. Figuring out how to best leverage a framework or library takes practice. Especially senior developers are quick to jump to the conclusion of something being “too complex” because they don’t understand something or lack the practice in this particular framework or library.
When encountering this, it’s important to outline how the statement of something being “too complex” is false, it’s just a matter of a more advanced usage of the software we use.

I remember being thought this lesson as a young developer with the attitude and failures of many other young developers: I knew it all. Luckily I had a patient teacher in Per Otto who had the patience and skills to learn me new things. Where I previously would just “hack together” some code, he introduced me to the Gang of Four patterns as a way to more elegantly solve some problems. What looked liked something needlessly complex for me without knowledge of them, turned out to be elegant ways to solve common problems with fewer chance of errors.

Not to my personal taste

Man appearing to be outside is licking on a deadly mushroom.
Photo by Anton Malanin on Unsplash

I have on a few occasions opted to use a framework called Hapi for writing HTTP based APIs in NodeJS. This is not the de-facto option which most developers use (which at the time of writing is Express), but it has some traits I personally really like. With few exceptions the choice of Hapi is always scrutinized by developers accustomed to Express, as they are developed with two totally different philosohpies. Where one is about freedom of choice and providing few opinions in how to do things (Express) and the other is all about making decisions and laying out a preferred path as to how to use the framework to get the most out of it (Hapi).

Being introduced to Hapi is always a bit of a hurdle as there are conventions and ways to do things you just have to accept. If you don’t you will only spend a lot of time fighting a fight you will loose in the end. Most developers opt to follow the path outlined by the author, while others choose to fight the premises on which the framework was authored on every single occasion.

The concept of plugins is central to Hapi and seasoned users of the framework tend to rely heavy on building their solutions as a series of plugins. This concept does not exist in Express and the introduction of writing a piece of domain specific code as a plugin is often met with utterances such as “it is too complex” or “this adds needless complexity to our app”. What I think they actually mean to say is that “this is an unfamiliar approach to solve this issue” and instead opt to solve the problem at hand in their usual manner instead of using the mechanisms built into the framework to solve these things.

What is deemed complex by someone not familiar with the framework, is viewed as an elegant and preferred way by those with more experience in the framework. Writing a Hapi plugin does require some more knowledge, but it follows the architectural patterns outlined by its author.

🎬 In closing

Be on the lookout for the word complexity being thrown around in technical discussions. Much like other powerful words such as performance and security, it is often used to disguise something else.

There are of course some solutions, frameworks and technologies which are more complex (Hello 👋🏼 container managed persistence with EJBs in the Java stack of early 2000s), so there are situations where the argument of something being too complex is appropriate.

A brown cow looking towards the camera with one eye.

Detecting bullshit 🚨

I remember when I first read How To Detect Bullshit by Scott Berkun, I was mesmerized that someone was able to articulate this so well. Throughout my career I have referenced this article to my coworkers. Today, more so than ever before, being able to detect bullshit is one of the most important skills you can have working as a programmer.

An endless stream of bullshit

There is an endless stream of bullshit flowing all over social- and traditional media at any given time. Previously it was not so constant and all consuming, but today you will encounter countless situations where the skill of bullshit detection is required.
If you fail to acquire this skill or do not practice it, you will end up making flawed decisions, make bad choices and maybe you even end up loosing your job over it!

Having a finely tuned bullshit filter is something that requires persistence in this day and age. If you do not force the filter to be applied to all information everything you consume, it will wear you down and you will be one of those people who’s only capable of reiterating something somebody else came up with.

I would argue that in all positions bullshit detection is essential. Obviously it is vital when being in involved in hiring processes. However you need to apply the same filter when working as a programmer and sysadmin. We are all bombarded with trends, hypes and promises of a new silver bullet every single day. A finely tuned bullshit filter is essential to be able to pick out the few important pieces that pass before your eyes during a day. Without it you’ll quickly feel exhausted and get a feeling you are not keeping up.

It only takes one question:

One of the first items in Berkun’s article is this, asking the question:

How do you know what you know❓

It sounds pretty easy, but once you focus upon asking this question every single time someone makes a statement, you will be surprised how often the answer will not be satisfactory.

Always be alert 👀

Let’s say you are visited by someone who’s portrayed as a thought leader in innovation. The first question you should ask yourself should be:
How does this person know what it claims to know?

In an argument with a fellow programmers when someone makes a claim that “X is superior to Y”, your first question should be:
How does this person know this?

drawing of computer program

An approach to problem solving with computer programs

When you start learning to code you develop an idea of what people who does it for a living knows. I remember when I started, I was convinced that everyone around me knew everything and was never in doubt about what the correct approach would be. There was little to read about how to approach coding except for academic articles and books.

In this day and age the situation is very different. There are countless resources where you can see how people approach problem solving using computer programs. You can watch live streams of people working on popular Open Source projects or watch tutorial videos. They all give good insight into the process of coding and shows how you can reason about issues you encounter. One thing you don’t get to see in these rehearsed videos is how they come up with the solutions and how they learned to solve it. In short, you don’t get to see their frantic googling, pulling of hair and general frustration which is usually involved. You don’t see the chat messages discussing topics and expressions of doubts about the solutions.

What I’m getting at, is that there are some things related to problem solving with computer programs which we don’t discuss that often and which is not shown in most coding videos. I will try to outline my preferred way of approaching a problem in an attempt to show that even though I have done this for a living in almost two decades, my approach is not one linear process where I know the steps nor the place I want to end up.

Make it visual

Regardless of wether it is coding up an UI component or creating an API endpoint to solve a data access issue, I have to make it visual. What I mean by that is that I got to draw something somewhere. It could be doodling something on a piece of paper, drawing on a white-board or putting some boxes’n things in a Google slide. This visual I try to update as learn more about the problem I’m trying to solve. More often than not I have to start over. Usually my first assumptions where wrong. That is not a problem! It means I’ve learned something and it’s better to “scrap” a drawing or slide than to revert code changes deployed in production. 

I have met programmers who are able to process things like this in their head. They are able to find design flaws etc by visualising what happens it in their head. This is something I struggle with. I can perhaps “run” a couple of steps of a process in my head, but then I loose it. My short term memory is terrible and I’m also not that great at keeping focus when thinking. Therefor I commit my thoughts to paper or some digital tool. One nice side effect of this is that documentation comes pretty easy, as I’ve been doing that throughout the problem solving process. 

The format in which I draw or the tool I use does not matter, it’s proximity and flexibility that matters. I find modelling tools constraining rather than helpful and enabling. Therefor I tend to use generic tools for visualising / drawing / doodling. There are formal approaches on how to modell software processes and create designs. Personally I find just “drawing whatever” is more useful then ensuring it is 100% correct UML syntax. I am not saying you should not seek learning techniques for modelling software. Everything you can learn which can be added to your toolbox is always worth checking out.

Large problems only? 

My process is the same for wether I’m trying to create some distributed architecture or if it is creating a small UI component. Once the issue requires me to think more than a couple of steps ahead, this is my go to approach and it is something I feel comfortable with. I find that there is no problem too small where this does not help. Sometimes my head just isn’t in it and doing some simple drawings works wonders for me.

Solving the problem

Once the design and preparation is done it is time to solve it. I use similar approach when it comes to writing the code for solving the problem. You can visualise the problem to solve with a drawing, but you can also visualise the flow of a program using text. I learned this approach reading the book Code Complete by Steve McConnel. He said that before writing actual programming statements, you can flesh out the details just using code comments. 

someFunction () {

  // if there is an item
    // render delete button
    // if not render the add button
  
    // write the label of the item
  // then add a parenthesis and a number

}

Once you have got some thing written down, read it back and see if it still makes sense. You should refactor the code block until it makes sense and it does what you meant it to. Perhaps you should extract a method or maybe you need to call out to a service and retrieve some more data. Refactoring when all you have is code comments is easy. As opposed fixing written and deployed code. I’m not saying this is something you must do, it is just one approach which I find helpful at times. 

There are other techniques, such as test driven development, which serves the same purpose as writing code comments before coding (I am aware there are more advantages, but this is not the topic of this post). Others use pseudocode to achieve the same thing (check out Thomas’ post on the topic  “I love pseudocode”). Learning multiple ways to solve problems is useful and something that will be beneficial regardless of the technological platform you happen to be working with.

“Kids, stay in school”

This article contains methods which happen to work well for me. Others will have different approaches and techniques. What is important is staying open minded and stay curious. To keep learning is essential to having a long career as a programmer. 

Hva er en god systemutvikler?

Dusty road in a desert landscape with a car
Veien til å bli en god systemutvikler er hompete, støvete og endere kanskje ikke der du tror.
Kilde: https://www.flickr.com/photos/honzasoukup/2398942904/

Hva er en god systemutvikler? Dette er et ladet spørsmål, så først vil jeg legge ned min definisjon av systemutvikling. Det er et lagspill der man sammen leverer en digital løsning på en utfordring / problem.Legg merke til at jeg ikke sier «hva er en god programmerer». Hvorfor ikke? Fordi programmeringsdelen er bare en  del av det som inngår i systemutvikling. Så, hvilke egenskaper trengs for å være en dyktig systemutvikler i 2018 og i tiden fremover? 

Kommunikasjon 

Du trenger først og fremst å være i stand til å kommunisere med de du jobber med. Det betyr at du kan gjøre deg og dine tanker forstått enten verbalt eller skriftlig. Det er sjelden man sitter alene og utvikler noe uten at man må kommunisere med noen. Dette gjelder både i jobb, men også i stor grad i feks Open Source. En del av det å kommunisere bra er å bli forstått, men også det å gjøre det på en måte som er positiv for de rundt deg. Hvis du sliter med kommunisere det du gjør, tenker eller mener så vil du merke at det å jobbe som systemutvikler kan være frustrende. Å kontinuerlig jobbe med hvordan du kommuniserer muntlig og skriftlig er en veldig viktig det av det å drive systemutvikling. Det er også viktig å forsøke mestre både den uformelle (f.eks chat) og den mer formelle som går på å skrive dokumentasjon eller lignende. 

Empati

Du trenger å være empatisk og forstå de rundt deg. Systemutvikling er å løse problemer for mennesker (startsett, noen ganger å løse problemer for andre maskiner etc men ofte er det mennesker) og da er evnen til å sette seg inn i deres situasjon essensielt. Spesielt i løpet av de siste årene har dette blitt viktig, da teknologien vi utvikler direkte påvirker menneskers lov. Hvis vi som utvikler disse løsningene gjør det uten et snev av empati gjør vi livet til de rundt oss verre, ikke bedre. Systemer utviklet uten tanke på de det påvirker kan få fatale konsekvenser og kan være skillet mellom liv og død (se https://www.nytimes.com/2018/10/15/technology/myanmar-facebook-genocide.html). 

Oppsummert

Kommunikasjon og empati er viktige for å være en bra systemutvikler i tiden fremover. Det betyr ikke at selve faget programmering er uvesentlig og at de to egenskapene jeg nevner gjør at du ikke trenger utvikle den faglige siden av systemutvikling. Det jeg mener er at i tillegg til kunnskaper i faget må du ha menneskelige egenskapene for å være en god systemutvikler. Tiden da systemutvikling var en solo greie er over og kommer aldri tilbake (heldigvis). Ei heller vil tiden da vi laget systemer bare for lolz være det. Det vi lager påvirker verden og menneskene i den, og det ansvaret som ligger på oss som utvikler systemene skal vi ta på alvor.

Kortslutning Podcast har en episode om samme tema, sjekk den ut: “Må du være lidenskaplig opptatt av programmering for å bli en bra utviklar?”