DEV Community: Mihailo Joksimovic

Integrate-first approach

Mihailo Joksimovic — Tue, 11 Jan 2022 16:13:30 +0000

Take it from a developer with 13+ years of experience.

One of the most common issues I keep seeing, especially when it comes to building more complex systems, is a tendency to delay the integration and focus on work in isolation.

Be it a frontend and backend integration, a microservice integration, or module-to-module communication, we always tend to avoid the pain of integrating by postponing it for our future selfes.

Let me tell you - THIS. IS. WRONG.

Not only is it wrong, but I've seen so many projects struggle (and occasionally) fail due to this. It's like everything goes perfect, sprint after sprint, but once we come to the "we have to integrate now", everything goes to hell.

It's literally the same as eating a cake now and hoping to go for a run later on! It's stupid!

So, take it from an ol' fella - always, and I mean ALWAYS focus on "integrate-first". Always focus on integration immediately, no matter how painful it is.

Chances are, 9 out of 10 times, you'll discover issues early on and minimize the pain to your future self!

Are you taking care of your Mental Debt?

Mihailo Joksimovic — Sun, 28 Nov 2021 11:11:30 +0000

I’m sure you’ve heard of the concept of technical debt, right? The idea pretty much boils down to – if you are writing a code, you are most likely creating a tech debt along the way. And if you DON’T repay the debt (e.g. by scheduling regular maintenance intervals), you will accumulate even more of it (called “interest” in finance) effectively paying way more than you would have paid initially. The end result? Bankruptcy. Your code becomes unmaintainable.

What I wasn’t aware of is where the term comes from. Turns out it was coined by Ward Cunningham back in 90s, where he used it as a comparison to a financial debt. A simple example is — you need machines to make money, and in order to purchase machines, you need money. It’s a chicken-egg problem, which you actually solve by introducing a debt – somebody borrows you money and they expect interest to be paid back (i.e. you pay back more than you borrowed, so they effectively have “interest” in borrowing it to you).

❗️❗️❗️ The problem arises if you don’t pay off the debt promptly. ❗️❗️❗️

It accumulates. And eventually leads you to bankruptcy.

Tech debt is the same. You make workarounds here and there in order to meet the deadline. You know, you skip some tests or write some hacky solution in order to have it done ASAP. Because, you know, deadlines. So you make a debt (in terms of shitty code) and if you don’t pay it back (by refactoring your shitty code), your code will become less and less maintainable and, in worst case, it will go bankrupt.

Now, here is a sad part. Every book out there recommends regular refactorings to maintain the tech debt. All cool. But what nobody talks about is MENTAL DEBT. How it’s created and how if not maintained properly it makes our mental state unusable.

💸 Mental Debt as a result of intellectual work

Here’s the thing:

❗️❗️❗️Doing ANY kind of intellectual work will produce MENTAL DEBT.❗️❗️❗️

Period.

Be it programming, designing or testing stuff, the moment you start immersing yourself in it, you are taxing your mental system. You are creating a mental debt!

And you know what? That’s absolutely OK! Because as you’ve (hopefully) read above — sometimes debt is the ONLY way to solve the chicken-egg problem. You do some longer hours, maybe a weekend here and there, … and if you’re in your early / mid 20s, maybe even pulling an all-nighter or two as well. And that’s OK! Making debt as a vehicle for bootstrapping your work is totally fine.

The problematic part, just like with financial or technical debt is – not repaying it back promptly. That creates “interest”, the side-effect of not paying your debt. And, you know what else is true?

❗️❗️❗️Letting it accumulate leads to a mental bankruptcy – THE BURNOUT!❗️❗️❗️

Now, question is – how do you know if you’ve accumulated some significant debt and interest on top of it? Here are some of the common manifestations that I’ve personally experienced:

Feeling frustrated about your work / boss / company / environment (you know – your boss is a dick, and your organization is a perfect example of a disorganization)
Thinking nobody is listening to you and only if they did, things would be different (you know – everyone’s stupid but you)
Having a belief that grass is greener on the other side (you know – all other companies are doing it way better than yours is!)
Having a general lack of energy and motivation (you know – just feeling flat after work)
Feeling like isolating yourself more and more and preferring to avoid social contacts (you know – feeling like staying at home 24/7 is a perfect idea)
etc.

You get the gist, right? It all follows the same pattern really – what you used to enjoy in the past is the source of frustration now.

So how do you deal with it then? You schedule regular paybacks, of course!

🛠 Maintaining your Mental Debt

I can’t really say whether you can completely get rid of the debt. Maybe you can. Maybe not. No clue.

But honestly, that’s not even the point of it. The point is that this debt EXISTS, it ACCUMULATES and you have to PAY IT BACK. And if you keep it at manageable level, it’ll be as good as not being there.

So how do you maintain your mental debt? Here’s what I suggest:

🧘‍♂️ Meditation — I pretty much see meditation the same way as disk defragmentation (some of you have to remember it!). It clears out the static, wipes out the noise and keeps your mental hygiene in check. I’m primarily using Headspace app, but you can also give a shot to Calm or do a simple search around Youtube for free materials.
📔 Journaling — interestingly enough, by writing things down you are LITERALLY getting them out of your head and making (mental) space for other things to come in. I personally use Day One desktop app, and I try to write daily. Even if it’s just a few lines, I still try to keep doing it day after day.
🏋️‍♀️ Exercise — shouldn’t come as a surprise, I hope? Exercising both keeps your physical health in check and helps you vent out that negative crap that you’ve been accumulating over time. Interestingly, if you keep it at 85% (without redlining yourself) you can actually feel recharged and even more energetic afterwards! So it’s like win-win situation 🙂
🧠 Therapy — It’s same as with teeth really. You can wash, you can floss, you can rinse, but at the end of the day, it’s the dentist that does the actual fixing. Therapy is simply an ultimate hero when it comes to cleanup of your mental debt. I’ve been attending REBT therapy for well over 7 years now. It did wonders. Obviously, you are free to try choose whatever will suit you, but, for the hell of it — JUST. DO. SOMETHING! I’ve heard positive stories with Psychodrama and Gestalt therapies as well.

And that’s about it. Everything that I suggest is battle-tested and proven to work by the author himself (yes, that’s me). Yours is simply to give it a shot.

👍 Your turn!

Now that you’ve hopefully learned about the negative effects of mental debt, and under assumption that you are willing to avoid the burnout, what I’d like you to do is to think of what will be the next steps that you are going to take. Is it journaling? A meditation? Starting to exercise? Or maybe even pondering the idea of starting the therapy?

Whatever you choose, my advice is to KEEP IT SIMPLE. Don’t overload yourself. Start in small steps, but stay disciplined. Make it part of your routine (and if you don’t have one – what a better time to create one now).

My daily routine is fairly simple – wake up, take a shower, meditate, write journal, hit the gym and start the work. And you know what? It works 🙂

Now, off you go and let me know what you decided!

How I Learned To Read (and read 30 books in a year)

Mihailo Joksimovic — Mon, 05 Jul 2021 18:02:29 +0000

Background

I was never an avid reader. Even calling myself a casual reader would be an exaggeration.. I just wasn’t into reading.

I somehow managed to go through school without reading a single book. No clue how I did it, but I did. And it worked out pretty well.

And then it happened … I got myself victim of all the ad bullshit that we’re being spoon-fed. “Stop working for others”, they said. “Be your own boss”, they said. “Stop working your ass off, so that your boss can drive a Ferrari”, they said. Become an entrepreneur and gain back your freedom!

And what do all the successful people do? They read, of course! 52 books per year; at least! Hell yeah!

It did have a positive effect though. It was 2012 and I got myself a Kindle (an e-book reader; highly recommended!).

First book? “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses“. Cheesy, right?

Reading for the sake of reading (and bullshitting about it)

This is unfortunate, but I didn’t realize it until recently. Pretty much most of my reading was focused on reading just for the sake of doing so.

I read some article that said that you have to be reading AT LEAST 20 pages per day, and being a good follower that I am, I obliged. I was reading 20 pages every night before I went to bed.

There was one funny instance which I clearly remember. I was reading Sapiens by Yuval Noah Harari (highly recommended read BTW). I finished the book and I had that feeling of satisfaction as I was able to add +1 to list of books that I read.

“How did you like the book?” asked a friend who recommended it. “I loved it! It was a real page-turner!”, I answered. “Great! What do you think about ________ and _________ ? How did you like those parts?”. I’ll be honest. I literally had no clue what he was talking about. Are we talking about the same book? Sapiens? It sounded like it for sure. But I have no recollection of even reading that. WTF?

That hit me hard. I realized that after 6 years of being an “avid reader”, I had no clue what I read in most of those books. Like, literally no freakin’ clue.

I was reading for the sake of reading and bullshitting about it!

The Pivot

It was time for a change. Even being heavily goal-oriented as I am, I decided to make shift. I’ll stop reading for the sake of turning the pages, and, instead, try putting more focus on WHAT I was reading. If I felt like reading two pages and shutting the book down, so be it!

Funny enough, this idea of SLOWING DOWN actually resulted in reading MORE than I would ever anticipate. According to Goodreads, I read 16 books in 2019th. This was more than I EVER read.

And then it happened.

You know how it works when you turn one small cog, and you don’t even realize that you actually started a whole machinery? That small step was small only on outwards. Inwards – the engine was warming up!

Everything I Knew About Reading Was Wrong

As I was gaining more confidence from reading (and starting to enjoy it), I was somehow figuring that it’s probably time to pimp up my game. It was time to go for some heavy artillery. Crime and Punishment (in it’s literal sense!) baby. It was Dostoyevsky o’clock!

Even thinking about it makes me laugh. I hated this book so much! Mostly because I couldn’t figure out what the hell was going on. I despised it!

But I was determined to finish it. You don’t drop a book half-way! It’s a book and a damn classic, for fucks sake!

I spent MONTHS fighting this book. It came to a point where even thinking about it would make me nauseous. And yet, I couldn’t start another book before I had this one finished. It’s a a BOOK for cripes sake! A damn classic!

Luckily, like it was sent from heavens, the article that would completely blow my mind and change my reading habits happened. I stumbled upon (and read in a single breath) a blog post called Everything I knew about reading was wrong.

Mind = blown.

Even though I wholeheartedly recommend reading the original, do be warned that it’s quite lengthy. And I will summarize it here for you.

It’s OK to read more than one book at a time

Sounds simple, right? Just read more books in parallel.

I saw it as heresy! Unwritten 11th deadly sin! The reader’s treason!

Hell, was I wrong, LOL …

I deeply believed that even thinking about reading more than one book at once would completely mess up everything. Like, I’d get overlapping stories and completely screw everything up. Obviously, I pondered this while having 150 Chrome tabs open, reading dozens of blog posts in fragments and checking tons of notifications on social networks. And yet, reading two books would completely mess my head up.

Let me put it as straight as possible here. It is absolutely OK to read more than one book at once. What’s more, it’s a preferred way of doing it!

There’s some logic behind it really. Some books are made to be read fast. Some are made to be read as a slow burn. Some you don’t even feel like reading today. And that’s all OK!

By giving yourself permission to read more than one book at a time, you are actually freeing up that mental space to read whatever you feel like reading at the time, and that results in reading EVEN MORE!

Just check my reading stats since then:

It’s OK to drop a book that you don’t like

Let me give you some stats that will blow you away.

Let’s assume that you are just starting to read when you are 25. And you manage to actively read until you are 75. That’s 50 years.

If you are doing average of 10 books per year, you will manage to do only 500 books! Yes, that’s for a lifetime!

Got my point? Just like you stop reading a blog post you dislike, it’s absolutely OK to drop a book that’s not “doing you” either! Save yourself some time and just read whatever you feel like reading. Your capacity is highly limited!

You don’t have to enjoy popular books

There’s this false belief that you should be enjoying what others liked as well. Yuck!

I was confused and bored by Fahrenheit 451 to the point that I didn’t even feel like posting a rating for it!

On the other hand, I do use recommendations as a source of narrowing down books that I’m going to read. Use it selectively and wisely!

Classics will call you when you are ready for them

This was also a misbelief that I had. I thought that a book that’s considered a “classic” is something that’s likeable by everyone.

No. Just … no.

The thing that I eventually learned about classics is that they will come to you. They will call you when you are ready for them.

Taking Dostoyevsky’s Crime and Punishment as an example, from my understanding (and do take this with a grain of salt), it is all about exploring human emotions. Guilt. Desperation. Fear. Regret.

And yet, at the time when I started reading it, I didn’t give a damn about that. I picked it up because it sounded like a cool thing to read.

On the other hand, I read Kafka’s The Trial at the time when I was feeling a bit stuck and depressed, and it just blew me away! I loved it! I’ll probably re-read it again!

My point being, when it comes to classics, don’t rush to them, but let them come towards you. You will know when you are ready.

Your turn!

It’s your turn now. Think of the books that you always wanted to read but you kept putting them away because you were stuck. Explore your library. Start reading multiple books! Immerse yourself and enjoy the journey!

Useful Resources

As usual, here are some resources that you might find useful:

Goodreads – it’s kind of a social network for readers. I use it primarily for exploring and keeping track of what I want to read. Feel free to befriend me there if you wish!
Reddit’s /r/suggestmeabook – a really cool place to browse for books as well. Sometimes I browse through simply for the sake of seeing the range of topics that other people are reading about. And it’s impressive!
Read What You Love Until You Love to Read by Naval Ravikant — Naval is just an amazing source of inspiration for many people. Among other things, he was a huge source of inspiration for the article above.
Everything I Knew About Reading Was Wrong — article that I’ve mentioned number of times throughout this post. It’s a bit lengthy but definitely worth giving it a shot Summary You are never too old to start reading! As the popular Chinese proverb says: “The best time to plant a tree was 20 years ago. The second best time is now” You should read more than one book at once. This allows you to immerse yourself in whatever your current mood and energy levels are up for. It’s ok to drop the book you don’t like. You have very limited time and amount of stuff that you can read. Choose wisely! You don’t have to like popular books. No book is suited for everybody. Read whatever you feel like reading. Skip classics if you are new to reading. You have to develop your reading skills first. You will know when you are ready for them!

Here’s why I see programming as an art form

Mihailo Joksimovic — Fri, 04 Jun 2021 13:23:01 +0000

Background

Funny enough, this wasn’t the first time I discussed this subject. But this conversation was different. The person sitting next to me was someone whose opinion I deeply respect. We were discussing a programmer that we both met recently.

“I could never do programming. It seems so boring to me”, said The Person. This truly shocked me. Is this really how people perceive programming? As a boring, dull, completely uncreative repetitive kind of thing? Holy cow!

“But that is so utterly wrong!”, I exclaimed. “It surely can feel like that, and it definitely is so from time to time, but that’s because what the concept of job is!”. I was shivering at this point. This really hit my nerve in a weird sense. I wasn’t pissed. No. It’s just that it was a first time that I realised that this is how ordinary people see programming. Yuck!

“Look”, I proceeded, “I absolutely see programming as an art form and programs as creative expressions of their creators”. “Hah! Why the hell would you think that?”, said The Person. Well, truth to be told – I had no clue. At the time, I was absolutely sure about it and I had bunch of unconnected ideas flying through my head. But I didn’t have a proper answer. “I don’t know”, I said, “but let me try writing an article on the matter and let’s see what happens”. And that’s how this article came to be 🙂

What is Art

As with probably everything that I contemplate and preach (or, as my GF would say – bullshit about), I usually start by consulting Wikipedia and official definition. I have no idea why, but it just feels like a good starting point towards something that I’m unsure about. Here it goes:

Art is a diverse range of human activities in creating visual, auditory or performing artifacts (artworks), expressing the author’s imaginative, conceptual ideas, or technical skill, intended to be appreciated primarily for their beauty or emotional power

Source: Wikipedia

Translated to my own words and how I explained it to The Person – artists use tools in order to create art. Painters use paintbrushes, writers use words, musicians use notes. They all use relevant tools to express themselves and to create something that people will admire. What’s so different about programming then? We use computer code as a tool for expressing thoughts, ideas and visions and we hope to be admired for it.

If you’re a programmer reading this, tell me – is there a piece of software that you coded that you are so damn proud of? That you wanted to show off? Maybe you didn’t show it around, but just secretly admired it? I’m sure you can remember at least one thing; if not many! Yep, that’s what I’m talking about! That’s your personal piece of art and you should be proud of it.

Food

What does food have to do with the programming related article? Bear with me.

Let’s focus on eggs as an example. They’re healthy and nutritious. Can be pretty tasty if made properly. But in general, eggs by itself are pretty dull. Just imagine your regular omelette or scrambled eggs. You might add some tomato, salt and cheese eventually, but most of the time it’s … just eggs. Plain, yellow, boring, …

And yet, some people, who happen to call themselves chefs, make a freakin’ art out of eggs! I have to break my habit of not adding images to article as I must show you what I’m talking about:

(Source: Eater.com)

Eggs. These are two boiled eggs. Plus some chips and whatever the sauce is. Can you resist admiring it? Feeling emotional about it? Even if you dislike eggs I’m pretty sure that you have to admire it for the sheer look of it!

The point that I’m trying to make here is – you can create an art out of anything really. As long as you enjoy doing it and want to express yourself in a way, the tool is irrelevant. It’s what you make out of it that matters.

Back to programming

I’m sure everyone’s aware that programming can be used for creating amazing stuff to be admired. Anything ranging from 3D animation and cartoons, all the way to spaceships and porn search engines. But the question that seems to puzzle most nogrammers* is – how the heck can programming itself be an artistic expression?

There are multiple ways. For starters, programming is not only about writing statements to screen. It is about finding solutions to a problem at hand. Solution itself is something that you can put some thought in and make it elegant and beautiful and have others admire it.

Optimizing and making existing code more efficient is another massive area. Be it by making it faster, less resourceful or just easier to understand, there’s that satisfaction of coming up with a way to make something better and just being proud for the heck of it!

Architecting systems is yet another beautiful area that brings plethora of options to let your imagination go wild. Everything ranging from modelling how the system interacts with outer world, all the way to evaluating and picking the technologies to use. It’s just as pure and as beautiful as it gets. Trust me.

Finally, just being a part of the bigger team that creates something great is another story on its own. That feeling when you can tell somebody – “see that beautiful thing over there? Yeah, I was a part of the team that built it!”. Overwhelming amount of joy caused by the fact that you put your signature into a beautiful end product is definitely something to be admired.

As you can see, there are so many aspects of programming where you have absolute and complete freedom to be creative. That, exactly, is something that I’m absolutely grateful for and that is why I see programming as an art form.

Fun fact: There’s a series of books called “The Art of Computer Programming”. There are four volumes published so far, totalling in over 3000 pages. These books are being referred to as “the bible of computer programming”. Bill Gates made a following statement about it: “If you think you’re a really good programmer… read Art of Computer Programming… You should definitely send me a résumé if you can read the whole thing”.

* nogrammer – a term used to describe a person who never programmed. I literally coined this term as I was writing this article, which makes it my little piece of art 🙂

Some personal examples

Let me give you some examples of my own. One of the pieces of code that I remember and admire to this day is a chess engine that I developed almost 10 years ago. It was my college graduation thesis and to this day I’m not sure if my mentor was joking or not when he told me to create it. Young & foolish as I was, I accepted the challenge. And I did it! (here’s a GitHub link to the main engine class). Boy, to this day, I still remember being proud of how I envisioned, designed and developed it. And it all worked like a charm!

Here’s another pretty recent example. I’m currently involved in an architectural position tasked with replacing the 15-year old system architecture with a more modern microservice oriented one. Do I even need to say how special I feel about every Microservice that we push through? Every architectural problem that we manage to solve? Or about every scaling or performance issue that we tackle?

You could argue that it’s more narcissism than artistry and you’d probably be right. I think it’s a mixture of both. But does that make it any less of an art? No!

Conclusion

Wikipedia defines art as a range of human activities performed with the idea of expressing author’s imaginative, conceptual or technical skills, intended to be appreciated for beauty or emotional power. What we, developers, are doing is using programming code for performing work that expresses our imaginative and conceptual ideas which we look forward to receiving feedback on and, hopefully, being admired for. That is exactly what makes us artists and that’s exactly why I see programming as an art form. Thank you! ** drops the mic **

“I don’t know how to manage people”

Mihailo Joksimovic — Wed, 12 May 2021 18:11:15 +0000

Background

Ever caught yourself saying it? “I’m good at what I do, but I suck at managing people”, or “I don’t really want to be a manager, I want to do actual stuff”, etc.?

If the answer is NO, I hate to inform you that this article is definitely not made for you and that you should leave. NOW.

If the answer is YES, then – welcome! You are most certainly not alone here!

Your profile

Let me go out of boundary here and try guessing your profile first.

I would say you are most likely in your late 20s, or early to mid 30s. You are probably doing a kind of job where you are solely responsible for the quality of work that you are producing (e.g. programming, design, marketing, writing, etc.) and, I would finally guess, you are most likely very good at it. A specialist, if I may say.

Does that sound like you? Or close enough? I’d bet it does!

Why this assumption? Well, it’s a wild guess for sure, but it simply fits the profile of all the people I’ve spoken to, who expressed this management concern. Myself included!

Real-life story

Let me tell you an actual story that played out not so long ago.

I was sitting in a cafe with a very good friend of mine, who also happens to be an insanely good developer. He has been programming for over 10 years now and is simply one of those top 3% guys that you’d name when you think of all the great programmers that you know. That kind of guy.

One thing that I always admired in him, besides his expertise in programming, was how he communicated to his peers and how he helped set goals and expectations with other colleagues. He is very direct, always has a solid vision and is not afraid to speak his mind. I admired him for these traits, but I guess I never voiced them out loud.

“We’ve been looking for a new Technical Director for a while now man”, he said, “but we just can’t find anything solid”. “Well, why don’t YOU apply for the position?”, I asked. “Nah man, I’m really great at programming, but I don’t know how to manage people”. I swear, my brain rebooted three times in a row.

“What do you mean ‘you don’t know how to manage people?’ You are a great programmer, amazingly clear and direct communicator, and you are not afraid to lead a difficult conversation. That makes you a PERFECT fit for the position!”. This actually puzzled him for a sec. “That’s interesting, I never thought about it in that way”.

Funny enough, neither did I. Until then at least. But six months later, and here I am, writing a blog post about it.

Why are we so anxious about it?

Yep, that’s right. I’ve been thinking about this a lot and one of the conclusions that I came to is that we are just scared of the unknown. Anxious, to be more precise.

“I don’t know how to manage people”, “I don’t want to be a manager, “I want to do actual stuff” and “I don’t want to bullshit and bother people”. Ever heard one of those? This is usually how we, the specialists, see people in managerial positions. God forbid if you’re on a C-level (e.g. CEO, CTO, etc.). That probably puts you in a “drink cocktail and bullshit whole day” category for us.

The truth is – we don’t really know. And how the hell should we know, if we never tried it before? But the trick is in the fact that it’s a big unknown. And we are wired to be anxious about unknowns (as you can imagine, I’m trying real hard not to drift off discussing the evolutionary benefits of this).

Specialists + Unknowns = Overwhelm

This is exactly what I think the deal is. On day one at your work you probably very much sucked at whatever it is that you were doing. Be it programming, design, marketing, writing, or just about anything, you most certainly sucked. But you didn’t care, because you were “allowed” to suck. The stakes were pretty low because you were junior.

But the time passes. And you get better at it. And if you never shifted towards the managerial waters, you probably spent 5 – 10 years improving your craftsmanship.

You know what also increases with the time? The stakes! Yeah, the better you become, the higher the expectation bar is set. And if you’re like me, you probably enjoy being good at something, right? Everybody loves being an expert and being respected for it!

But then, the point comes when your manager (hopefully) recognises that you should share your knowledge with young padawans. They start steering you towards the managerial / lead roles and, unless you were prepared for it, the panic arises! “I don’t know how to manage people. I want to do actual stuff!”. You’re freaking out.

What’s really happening here?

I actually heard a perfect metaphor for this. Every situation that you face in your life is like an onion. The more you peel it down, the more teary you become.

If we peel couple layers off, what we actually have is a person who is amazingly good at what they are doing, now being faced with something they never did before. They are at the risk of losing the reputation that they’ve worked so hard to build, because, this is something that they never tried before! And who wants to go back to square one and being at a junior level, after having invested 5-10 years of hard work, right?

That, in my opinion, is exactly what’s at stake here – our reputation and the risk of sucking at something new! And we’d rather avoid that and stick to what’s familiar. At least most of us 🙂

It’s ok to suck

Let me put this bluntly before I proceed any further. It is, undeniably and unquestionably OK to suck at something that you never did before! Let me say that again – it’s absolutely OK to suck at stuff you never tried before!

It seems like I can’t write a single article without referencing one of my older posts – Do something that you suck at. If you never read it, I’d strongly urge you to check it out.

Anyway, my point is that your superior is probably aware of this already, and it’s likely that they’ve gone through the same tango earlier in their career. So you are, hopefully, not expected to give A+ performance the day one.

But!

And there’s always that “but”. It’s OK to suck, but, it’s not OK to use that as an excuse not to get better at it!

Just go back to day one when you started your work. You sucked, right? But you were OK with it because you knew that it’s OK to suck and you were eager to get better at it. Well, the same strategy applies here as well. Just like with anything else in life really – you start from square one and you rinse & repeat until you improve your game. 5 – 10 years later and you are, hopefully, A+ again. At that time, you’re probably going to google for “I don’t know how to be C-level executive” 🙂

Most important thing that I learned on “people management”

If I summarised everything that I’ve read, learned and heard about over all these years, it’d boil down to one really simple sentence – You are NOT supposed to manage people.

Yep, you’ve read that right. People are not a flock of sheep or a commodity to be managed. Every single teammate of yours is a conscious, living being with their own set of ideas, desires and thoughts on how to get something achieved.

There surely are areas where you can force people to do what you want them to do, the way you want them to do it. Sure. I haven’t checked the dictionary though, but I’d say the word for that is not management, but slavery. And nobody likes being a slave!

Your job is to set goals and help people achieve them

That’s right. You are not supposed to “manage people” but to “manage goals & expectations”. You are supposed to explain to people where you want to go (the destination), to ensure that they have necessary tools & skills and, believe it or not, to either join them or get the f*ck out of their way!

Sounds so simple and easy, right? It sure is “simple”, but “easy”? Absolutely not. And that’s where you will most likely suck. Maybe even big time! But it’s your responsibility to train and educate yourself enough so that you get better and better over time.

Resources that I found useful

Discussing what I learned so far, along with all the mistakes and f*ckups I made would probably make for a whole article, if not even a series of articles. Give me couple more years and it’ll be a whole book. But I’ll trim it down to some of the most interesting resources & ideas that I’ve stumbled along.

I’ll go with some resources first:

Extreme Ownership – this is a book that you might even have heard of before. It is a piece written by two retired U.S. Navy SEALs, Jocko Willink and Leif Babin where they discuss the leadership lessons that they learned as commanders of SEAL teams. I actually even went as far as noting down all the important lessons that I picked from this book, so you could imagine how much I enjoyed it. P.S. The follow-up version (The Dichotomy of leadership) is nowhere good as this one, so feel free to skip it.
The Phoenix Project – if you’ve ever heard of “CIO” meaning “Career Is Over” (instead of “Chief Information Officer”), well, that comes from this book. This is just one of those books that your manager has probably read, because it was suggested by his manager, who got this as a suggestion from their manager. Also one of those books that, as you read it, you start wondering if somebody wrote a book about yourself!
The Five Dysfunctions of a Team – yet another gem that, along with The Phoenix project, I literally read within 5 days. One of the most mind-blowing things I’ve learned here is that “Conflicts are GOOD thing!”.
Difficult Conversations – you know, I’m one of those people who used to be shit-scared of conflicts and difficult conversations. Well, after reading this book, I’m just scared but I chose to do them now. One of the essential books in a toolbox. I never wrote a review for it but I did extract some lessons that I might publish as a separate blog post
Tools of Titans – this book is like one of those vegan bundles that you keep buying for others and farting about day and night. I’ve read it THREE times, cover to cover, and I’ll probably keep re-reading it forever. What I really love about this book is that it takes all the people who we see as successful and distills them to basics. And what you learn out of those basics is that they themself suck(ed) at whatever it is that they are doing, but they just accepted it and kept sucking until they didn’t suck any more. Of course, here’s my review of it.

I think that’s a good starter kit for now. I’d also additionally recommend podcasts with Jocko Willink, David Goggins and Andy Stumpf. I also liked listening to guys who just experience “sucking at stuff” as a fun thing to do. If you’re into niche like that, search for podcasts with Jesse Itzler (he wrote a cool book – Living with a SEAL, which is an amazing read!) and Dan Bilzerian.

Conclusion

We are all scared of the unknowns. Especially if we spent number of years improving our skillset and becoming the expert in what we do. Losing the throne for something that we might suck hard time at can be a scary thing to do. Yet, if we realise that it’s OK to start from scratch and that we can actually educate ourselves upfront, we’re already halfway there to becoming great at this as well! Plus, you need to remember that your job is NOT to manage people but to set clear goals and provide resources and assistance for people to achieve them. Hence it boils down to having a vision, clear communication and patience to (re)learn that every beginning sucks, but we get better over time. Good luck!

Story Points that mistook themselves for Hours

Mihailo Joksimovic — Wed, 24 Mar 2021 19:28:25 +0000

Background

It’s funny really. For whatever reason, I always assumed that pretty much anybody who uses story points actually knows WHAT they are. And why they are different than hours.

Yet, as in pretty much all of my assumptions that I end up writing about – I was wrong. And not just “wrong” but wrong wrong.

“Story points are the same as hours”
“Why use one instead the another?”
“Why are you bothering at all?” etc.

Let me put this straight — story points are NOT hours! And this article is all about explaining WHYs behind that.

Real-life story

It was September I think. Probably mid-September. That crap time of year when you know that summer is about to be over. Everything’s moving towards yellow. Bye bye green.

I remember it clearly as if it was yesterday. We had around 30 components to estimate. Estimate as in – estimate how long would it take to have them finished.

“Let’s just use story points”, I said. My colleague frowned. “Nah, let’s just use hours. Why bother?”.

Weird, I thought. We’ve been using story points all along and yet, we’re discussing hours again. “But, WHY?”, I exclaimed.

“Man, I just know that each component will take us around 3-4 hours to finish. Why use story points if I know exactly how long will it take?”. Good point, I thought. Good point. Why use story points if we know exactly how long will something take, right? I agreed. It doesn’t make sense.

“Let’s add some buffer and agree on 6 then?”. We agreed on that one.

30 components times 6 hours equals 180 hours. Perfectly calculated and communicated to the stakeholders. The deadline was set (yes, this is INEVITABLE!). The clock started ticking.

Well, if I were to tell you that we finished all of this in ~180 hours, this story would be boring, right? Luckily, it won’t.

What actually happened is that after finishing the FIRST component, we realized we forgot to calculate for some additional stuff that HAD TO be done for every single component. So it took us around 9 hours to finish a single one. And this was true for every next to come! We under-estimated by three hours per component, which gives us total of 90 hours that we didn’t count on! Ouch!

Now, if you’re working in a low-paced environment with a handful of stakeholders, you probably have no problems just adjusting everything (and the deadline). However, if you’re part of a highly paced environment with many stakeholders along the lines, you’re in for a wild ride.

Alternate ending – using story points instead of hours

Let’s just imagine for a second that instead of saying 6 hours per component, we said – 6 points. So, 30 components times 6 equals 180 points. So, what’s the estimate of our work? 180 points.

Now we start working on our components and we realize that each component takes around 9 hours to finish. After a couple of days, we’re pretty sure that each component will take that much time. And now we’re ready to make a final calculation – 6 points seem to take around 9 hours to finish. 30 components times 9 equals 270. Add some buffer and we could have communicated 300 hours to the stakeholders. And we’d meed that deadline easily!

So in this alternate ending, what we really did is that we communicated the COMPLEXITY (in points) of work that needs to be done, and yet we took some time upfront to actually learn how long will it take. Approximately at least. And take my word for it, as much as anyone whines, you can always afford some time upfront to actually figure out the size of your backlog.

Story points are not hours; they are complexities!

Frankly, people seem to have problem with this statement. And, in my personal opinion, the issue comes from the fact that when we say “points” we usually use numbers. And, naturally, when you see an estimate in a number, especially when talking about a programming task, your natural inclination is to append measurement unit.

As in – what’s the estimate of that? “60”. It’s just awkward. “60 points”. Nah, we need something tangible. “60 hours”! Right, that makes sense now. Except not! But before I get you to understand this, I first have to explain WHY use story points in the first place.

Why use Story Points?

Because people suck at estimating stuff. As simple as that. We all pretty much suck at estimating hours, distances, sizes (as every man surely knows), etc. Just think of every instance where you thought something will take 5 minutes and, lo and behold, 6 hours later you’re scratching your head.

Why do we suck? No idea. There are bunch of explanations and, if you’re in for it, go and google it. The point that you must keep in mind is – you suck at estimating stuff. And instead of trying to figure out the WHYs, in this specific scenario, I’d like you to focus on tools that we can use to leverage that. Think of it as quantum physics. We pretty much have no clue what’s happening there but we do have rules and approximations that are good enough to do what we need. So we leave WHY to philosophy and we focus on doing what we can – applied physics.

Now, we do suck at providing precise measurements, but turns out that we’re pretty damn good when it comes to COMPARING things.

Just look at this image:

If I were to ask you what the size of each object on the image is, you’d probably need something like 10-30 secs and you’d come up with some measurements that might be right. Or wrong. Who knows.

And yet, if I were to ask you to group these items into couple of categories, say – small, medium and large, you’d need exactly 3 seconds to do this. Even though each item is rendered in the same size, you’d need no more than couple of seconds to conclude that kindle and notebook are medium, coin is small and laptop is big. And the table with all these items? Well that one should be broken down into smaller components – couple of books (medium), laptop (large), phone (medium) and pencils (small).

If you want to make it more precise, you could use – extra small, small, medium, large, extra large. Pretty much sky is the limit. And you should be free to pick whatever you feel like picking.

So how does this translate into story points, right? Well, pretty easy – take any object that you want and make it a “reference” object. Now compare everything relative to it. So, let’s say that Kindle is “5”. Since notebook is similar in size, that makes it “5” as well. Coin is way smaller, so we make it “1”. Laptop is way bigger so we make it “10”. And the table with bunch of items – well that needs splitting, so we make it infinitely large.

How to use Story Points to estimate tasks?

It’s actually pretty damn simple. You take a list of tasks, you pick one as a “reference” and you compare everything to it. Or you could take the smallest (1 point) and biggest task (100 points) and compare everything relative to that. If there’s something you can’t compare (i.e. you can’t put it into a proper bin) – you mark it as infinity and leave it for later on to be discussed and split if needed.

And this is really effective for two reasons (that I’m aware of):

It’s way more natural (and easy) to compare things relative to each other, and
It saves time and frees up cognitive space

What people usually do is use some sort of a planning game, for example a “Planning Poker” (more commonly known as “Scrum Poker”). In a nutshell, the way this works is that every person gets a deck of cards with numbers (e.g. 1, 5, 10, 50, 100, infinity) and product owner starts reading tasks that need to be estimated. Every person picks a card that he thinks that matches the “estimate” of the task and places it, face-down, to the table (so that others can’t see it). Once everybody is done playing their cards, they are opened and we try to see the pattern. If all cards are similar then we clearly have a winner. But if we have big gap between smallest and biggest (e.g. 1 and 50), then we have people discuss and try and agree on the estimate.

Once you are done estimating all tasks, next step is to try and figure out how much you can finish within a sprint (e.g. in 2 weeks). Frankly, you have no clue, especially if you’re just starting, so you just pick randomly. You pick one big, two medium sized and five small tasks. Let’s say that accounts for 90 points. So you work on them and at the end of the week you realized that you either underestimated, over-estimated or, if you are really lucky – you picked the right amount of work that you could finish (rarely possible). Based on what you did (under- or overestimate), for the next sprint you modify the amount of work you take in. And you repeat this until you get it just about right. And there, couple of sprints in and you get to know your velocity (i.e. how much you can finish within a sprint). Now you are ready to pimp up your game and try to map the size of your backlog from points to hours, effectively giving you the roadmap 😉

You don’t need to use numbers!

That’s right. Numbers are used mostly because they are convenient. But you are absolutely free to use any other measurement that works for you really!

For example, in my current company, we used to use t-shirt sizes for estimating huge chunks of work. As in – S, M, L and XL.

I’ve also seen people use animals – ant, dog, horse, rhino, etc.

Story points are measure of complexity and it’s really up to you how you want to write them down. It’s just that it’s a bit more convenient to say that you’re burning down 30 points instead of 15 ants, 5 dogs, 2 horses and 1 rhino. But really, at the end of the day, it’s up to you.

Don’t go too crazy

It’s usually recommended to use Fibonacci-like sequence. And people seem to take this literally and use 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.

Uncle Bob in his Clean Agile book has the perfect advice here. What he says is – “what you want to do with these numbers is to get rid of most of them”.

Make it simple. 1, 20, 50 and 100 are perfect for the beginning. Estimate your tasks with these and then break it down further if needed. But again – don’t go too wild or you’ll overload (and hate) yourself!

Conclusion

It’s a matter of fact – we all suck at estimating things in hours, inches, centimetres, etc. And yet, we are pretty good when it comes to comparing things relative to each other. Story points leverage this idea by giving you a framework of categorizing things. Measuring complexities, as we like to say. And if you need a final thought on why the story points are not the same as hours, let me put it this way – because.

Original Source

This article was, originally, published on my blog as part of the "Agile" series. Other articles that might be of interest are - "Oh no, daily again!" and "The Product Owner's Curse".