Evolution of Engineer - critical neurone mass and negative code value
Code is a cost and has a negative value, yes I said it finally.
In 2013, I went to the 2nd edition of DevDay. This was my first conference ever in the different city. It was a blast. The team behind it recently started a new event - DevConf - knowing Rafal and Michal it will be great, check it out.
In 2013, I remembered one talk about building products. Why might you ask? Well, It is an outrage! The stuff speaker said back then was challenging my engineer-centric world view. How he could say that business is most important. That there are companies building crap products and making money out of it. Engineering is my life, I strive to create perfect code, perfect products. Go away with you corporate/managerial tools of oppression. You will not force me to build ‘crap’. How could he say that TDD is not important at all when it doesn’t bring any value. This is tech conference please speak about technical stuff, not some business mumbo jumbo. Who cares about the business side. I am here to learn how to build beautiful things, I am a craftsman. Show me the code! It was shocking disappointment. I won’t listen to this guy anymore … if I only knew how wrong I was.
Those were my ‘junior’ years. A magical time when you get the first job. You quickly realise that all the cool things you learned in the books - beautiful code, craftsmanship etc. are actually unknown or not used in the ‘real world’. This was painful. All I cared was the code, business phew, I didn’t mastered Engineering degree to think about business. Come on! I am an engineer, I build things not sell them. This stuff is for managers and other people that steal my precious time on useless meetings. Oh, look new framework! Yeah! Hey, why won’t we rewrite our platform? Anyone?
Critical neurone mass. This is my name for phenomena (I have no idea if this exists) when you gather information, concepts, ideas that look useless at the time but will have a ‘transforming’ impact in the future. All you need to do is reach the critical mass. This is the time when you got enough of knowledge and experience, to finally get it. The point of no return has been reached, there is no coming back. Neurones are ready and your brain structure has a different shape. Clarity and new you takes over the handle. Everything makes sense, you are ready for more. What happened in 2013 was a beginning. The first step in a long-running process of me understanding the big picture and business/tech relation in IT. This talk, which generated emotions, was a seed that started the process.
I was not ready. Living my happy engineering life, I moved on and ignored the talk. Ignorance is bliss and easy. More projects, more code, more problems and solutions. Still, from time to time, I stumbled upon something that reminded me that something is out there - Don’t call yourself a programmer. After reading this blog post, which was challenging again, my reaction was different. I said ‘Huh, interesting’ and moved on. No hardcore emotions this time. Something was changing.
Experience and knowledge, both are important to growing. Knowledge is where you get new concepts, ideas and techniques. Experience is where you use and apply them. Without new knowledge, you wouldn’t know where to go next and what to try. Without experience, you might become ‘expert beginner’, Someone who knows how to talk a lot but doesn’t know how to do stuff. It is important to learn by usage. It is obvious, right? We know it as - if you want to learn new programming language, build something. I am learning Go now. I could read guides, books etc. but without actually building something it will be useless. To understand more advanced topics, I need experience. I need to fell the pain of my mistakes, lack of knowledge and struggle. With this, the reading is filled with my personal feelings. Hey, I know this problem, I was fighting with it for some time, oh yeah this is obvious.
My first ‘date’ with Eric Evans. I gained more experience, became mid developer, and started working with Mirek Praglowski. If you know Mirek he is into DDD - DDD this, DDD that, aggregate, value object and domain events you fool. It is not a coincidence that he works now in Arkency - a company full of DDD experts. Mirek even asked DDD questions to my friend Pawel Sawicz on the interview. I was a bit concerned because I didn’t have a clue about Domain Driven Design. Shit, if this is part of an interview process, I need to know it. Fast, let’s get the book and read it, Done! Well, not soo fast Michal. My initial reaction to the book was … well … hmm, how to say it … BORING! I am bored to death. I don’t get it. The thing that stayed with me was ubiquitous language and I got some hints that there is actually business somewhere. I was looking for the code again. Where is the code, Eric? All my work problems were around code, all I was looking for were solutions to problems I had. Mirek convinced our company to send us to Vaughn Vernon workshop. Code finally! Hurrey awesome, yeah … Java? … come on! Why Java … ( btw there was also a talk about Actor model pattern with Akka I didn’t get it either ). It was a bit better, finally, something hit me, but there was more to come. What is important, my engineering radar noticed ‘Business’ once again.
Without experience, we won’t understand. I didn’t get DDD or Akka because I wasn’t working on problems that could benefit from it. It was impossible for me to understand the importance of DDD. Such a mental shift would be understood, only with the experience of modelling complex business domain. I was working in projects that were complex. But the big picture was still invisible to me. I was still too junior to even want to understand the bigger scope. I had to wait 2 more years to get it. Thanks to Mirek and Workshop, I knew at least that there are things that could be useful one day. I had to wait for the time to face problems that would use them.
I see light - oh wait it is the business value after all. I moved to London to JustGiving and became a Senior dev. I was facing interesting problems, had a great lead Pete Dobbs and had to interact with the business on my daily basis to build things. Huh, the code was still important, but I felt inside that there are more things that need handling, like building domain knowledge, establishing relationships with stakeholders, understanding why I am actually building this thing. Where did, I get this feeling? How did it happen? Am I becoming a manager now? so it was true that all the roads go to ‘Management role’ … noooooo. After some time I got promoted to a Lead role ( I always wanted to do this thanks to Roy Osherove book ). My role has changed, code was part of it but not the most important part. I did coaching, mentoring, establishing practices, selling the team across the org, helping devs to be heard, evolving team culture, building relationship around org, establishing product strategy, working on roadmap … a lot of different things not related to my engineering side. All this helped me to finally understand.
“Engineers are hired to create business value, not to program things”- Patrick McKenzie
The Code is a cost. Its value is negative. Yes without code there wouldn’t be a product. But on its own, it is worth nothing. Code generates value only if the product is used. To get a customer/user, there are many more variables involved: marketing, market-fit, usability, design to name few. Code is just a tool and not the only one. There are certain problems that don’t even require the code at all. Our job is to find solutions, sometimes this solution can be solved without code.Each line means new costs have been acquired. It is like with the concept of money. The value of a currency is only a social contract. You have to buy something to cash in. On its own money is worth nothing. The same is with the code. If you have a beautiful code it doesn’t mean anything on its own. It has to be used by someone to generate the value.
Perfect design, the clean code doesn’t mean anything. As a junior, I was soo focused on writing code that writing it was a goal on its own. I was focusing on engineering problems ignoring the business side of it. It was like some sacred magic ritual. Now the code is one of the tools to find solutions. Experience engineer solves problems and knows if having the beautiful code is worth the time and value. There are different projects, different contexts and different strategies. It is ok to hack quick product as soon as possible and grab the market opportunity. This opportunity might be gone next month. Do you want to risk it while spending time designing your perfect ‘organism’?
“Stop Over-Engenering” - Greg Young
Good enough code. There are many flavours of how you can write software. It’s not either bad or good. You have to adapt your solution to the challenges and context ahead. Adapt, analyse - understand the true needs of your client or future users. Don’t try to adapt those to your ego-centring engineering needs. Provided solution has to be merely good enough to generate value. Good Enough? What does it mean? Sometimes it can mean horribly hacked code just to prove an idea, or confirm the market. Other time it can be nicely designed easily maintainable and lasting solution. It all depends on the context.
Evolution. I am working for Just Eat now. Part of my onboarding process I have checked the code, tech stack, devops solutions etc. But the other part that I am more interested in is business side.
- What are the challenges?
- What is our competition doing?
- Who is sponsoring this work?
- Who is supporting it?
- What are we doing to get to our Goals?
- What is our metrics?
- Are teams aligned to metrics and goals?
- How do we recognise if we are successful?
All these matters as much as tech, scale, reliability. Finding a balance between business and tech is difficult.
What happened to me. Am I still Engineer? Who am I?
I have no idea how to classify myself anymore.
Thanks Ben for your talk in 2013.