Category: All

Dealing with Business Anxiety

Do you ever feel anxious meeting new people, be it customers, peers, supervisors, stakeholders? Do you even feel anxious meeting with a group of colleagues you already know? Does the thought of speaking up in meetings, lunch breaks and office hallways make you feel nervous? If any of these are true for you, keep reading to discover a simple set of techniques that have somewhat helped me overcome these challenges.

For the impatient ones, here’s the summary:

  1. Know thy purpose – prepare for a conversation/meeting upfront.
  2. Be good – towards yourself, other people involved in the conversation, and beyond.
  3. Radical acceptance – be willing to accept whatever outcome might happen.
  4. Hoping for the best – keep your spirits high.

Know thy purpose

I was sweating, could not sit still, and my heart was pounding, as the thoughts like “Is he going to think I am stupid?” ran through my head. This was in 2018 in Belgrade, Serbia. I was having a lunch meeting with a guy that would later become my personal coach, when he noticed I seemed to be nervous. He asked “what’s up man?” and I said “I feel anxious about meeting new people”. He asked “why are you meeting with me right now?” and I said “to learn from you”. Then he said “keep that in mind as your goal for this conversation – to learn something new. As soon as you see you are not getting that out of the conversation – feel free to leave”. Just like that, the panic subsided, and so I have used this trick ever since.

It is not guaranteed to work for everybody, as all people are different, but I hope it will work for you. The basic premise is to know why you are entering an interaction with someone. When anxiety kicks in, remember the purpose with which you are meeting. Evaluate what you need to do to meet that purpose, or if it is time to give up, get up, and leave.

Another thing to think about is to have a “grand purpose”, something that transcends the individual moments of our lives. Think something along the lines of what I wrote in the article titled “Introspection via the Who-am-I document“. More about this below.

Be good

Oftentimes, I used to think – “am I going to be perceived as overly selfish, or greedy, am I asking for too much”? This has been a source of anxiety for me in business settings. I am ambitious, I have always been. It is a natural tendency for many people I guess, including myself. I like a good challenge and a reward. Alas, somewhere along my journey, the idea that I am a greedy, or overly-ambitious, self-centered ass, creeped into my head. And I am grateful for that, even though this self-doubt has caused tons of emotional pain, such as anxiety, and noise in my thinking and behavior. I dare to say, that little voice might have been correct, if not compassionate. Eventually that ill self-criticism helped me move forward in my journey.

This thought manifested as anxiety at work mostly because I would receive feedback that I am abrasive, selfish, demanding, rude, and such (all true, at the time at least), without being able to understand exactly why or how to improve. The good thing is that, more or less, I have learned to receive feedback to heart, and contemplate these things. My “ambitious” spirit could not handle that I am operating at a “sub-par” quality as a person. Hence, mission accepted! The goal – improve your character. The reward? Feel better about yourself, and be at peace. Wonderful!

For example… It was hard for me to “influence” others (politely). Even now I struggle with this. It’s not easy to break away from old habits. So again, in 2018 I established a mentoring relationship at work, with a senior leader of the company. I asked about “how do I learn to influence others, efficiently and without anxiety?”. My mentor quickly recommended that I check out the book titled Influence without Authority (rated 3.6/5 on GoodReads). This book is not something I would recommend verbatim, but eventually it did help me get toward the mindset I am happy with now. The premise of the book is that “if you want something from someone, you have to give something that they value in return”. Also known as “quid-pro-quo”, or “something-for-something” or “this-for-that”. In retrospective, this is not quite my favorite mindset to live by, but, at least it’s a step forward from my previous mindset, which was more along the lines of “quid-because-I-say-so”. Quite arrogant from the less-experienced Srecko, I know. That arrogance still lurks in me, like a dark shadow, and it still gets out in the open when I am under stress. Alas!

That quid-pro-quo mindset made me realize the next step in my “business-grand-awakening” – and that is simply to be in service of others. Quid-pro-nothing. Now, when I look into a business, or something that needs to be organized, influenced and so on – I don’t do it because I expect a “special reward” for it. I do it because I figure that in the grand-scheme-of-things, that is the best course for everybody involved. It’s optimal, not just for me, but for you, him, her, them. Literally what it should mean to be a team player. We all win or lose together as a team, as a company and so on.

I know this sounds cliche. Give it a try, it might work for you too. Different strokes for different folks. It is not guaranteed to work for everybody, but, if you are more like me then it’s more likely to work, I guess. Move from “quid-pro-quo” to “quid-pro-nothing”. Be in service of others. Be and do “good”. Do the right thing. Be wise – there’s more to life than self-promotion, personal achievements, and being a hero. Make the right moves – not to get something for yourself, but for the greater good. Optimize for the group. As another friend and mentor told me once about the stock market – “All ships rise and fall with the tide” – well, same is true for leadership, communities, and office-work. You could promote yourself forward in the org chart, but if you leave dead bodies behind and destroy everything on your path – what have you accomplished if not to be the last person standing on a sinking ship?

For many people this will not feel natural, and that is okay. It is not meant to work for everybody. If you are still searching for your leadership style, and modus operandi, then, at least consider it. Some alternatives to this mindset are the likes of machievelism, every-person-for-themselves, stab in the back, never help anyone mindset that you might see with Gavin Belson in the hilarious HBO TV show “Sillicon Valley”. Frankly, I see nothing wrong with that being “the truth” for some people. Whatever makes you happy!

Radical acceptance

Me: “Oh my God, I am so happy this is over… how did it go?”

Shadow: “Not that great. You seem a bit nervous?”

Me: “Yeah, I think I did a terrible job. I felt so lost during the process.”

Shadow: “What’s the worst thing that happened?”

Me: “I might have messed up the interview, the candidate might have thought I am a phony…”

Shadow: “Even then, so what? What’s the worst that could have happened? To deal with anxiety, always prepare for the worst in advance, and then hope for the best.”

“Behavioral” interview training, long time ago.

Probably by a systemic mistake, I was pulled into an interview at one of my previous jobs, that I wasn’t quite qualified to do, yet. I was scared to reject it, as I thought something bad would happen if I did. Interviewing prospective candidates was a big deal, and I already had around 50 or so “coding” interviews under my belt. What could go wrong with one more, slightly different interview, it’s not a rocket science, is it? So I went along, and accepted the interview I was absolutely unprepared for. The “behavioral” interview is supposed to assess the “cultural fit” of a candidate with the company’s own peculiar ways of doing things. Well, I hate to say it, but I had little to no idea what the culture was myself, let alone how to assess someone else on it. Fake it ’till you make it, they say. I went online and researched what “behavioral” interviewing is about. I gathered and memorized a bunch of questions from the internal knowledge base. With the basic training and a bit of reading, I went into the interviewing room, absolutely terrified of what might happen… The “shadow” (a far more experienced engineer and interviewer) was accompanying me to observe my work. The candidate entered the room.

One, after another, after another – I asked 50 different questions, in a frenzy…

Me: “Can you give me an example of you disagreeing with your boss?”

Candidate shares an example X.

Me: “Aha, OK. Can you give me an example of a mistake you made?”

Candidate shares an example Y.

Me: [asks no follow up questions] – “Aha, OK. Tell me about a time you were proud of yourself?”

… and so on and so forth.

Yours Truly conducting a Behavioral Interview

Okay, so, on a scale of 1 to 10, that interview was probably about “2”… meaning, it was not a total disaster, but it was far from being even remotely good (7) or mediocre (5). I blew it. Ever since this event, I stopped interviewing candidates. I get panic attacks just thinking about it. Alas, I did learn one thing. 1) do not “fake it till you make it” in interviewing, (2) if you have to interview, know what you are doing, and even if you don’t, make sure to ask some follow up questions so that it at least seems like you know what you are doing, and most importantly (3) when dealing with anxiety, it helps to prepare for the worst in advance.

The wise Shadow told me that “preparing for the worst” is a mental exercise that helped him deal with anxiety. Analyzing the situation you are getting into in advance, and imagining your biggest fears and undesired outcomes, and then saying “yolo, even if that happens, I will survive / I will be OK / I will take actions XYZ and move on” helps a lot. Throughout the years I have used this advice to deal with situations inside and outside of the office.

Just as in the previous section, this advice is not the best mantra to live by, at least not for me, but it was a great stepping stone towards my next realization – and that is radical acceptance. Radical empathy, too (reminds me of an episode from Star Trek – Strange New Worlds…). Here is the deal. Preparing for the worst is good. But having radical acceptance is the best, when possible. Preparing for the worst means you imagine negative outcomes (that almost never happen) and how would you react to them, therefore curbing your anxieties. But the real deal for me was when I realized radical acceptance – it is not something that can be taught, though. Unlike “preparing for the worst” which is a technique you can try and master, the radical acceptance is more of a state that you achieve at some point. It is a state of bliss where you no longer cling to outcomes. The wisdom of Mark Manson, the author of “The Subtle Art of Not Giving a F*ck”, comes to mind. He wrote a bit about perfectionism, self-loathing, self-esteem and such topics. I recommend you check out his page at https://markmanson.net/

Hoping for the Best

To wrap things up, once you are prepared, you know thy purpose and have a solid motivation, and ready for whatever outcome might be, then go in, hoping for the best outcome. Simple as that.

This is not a silver bullet recipe. It will not work for everybody. It will probably not work for most people. It did work for me, I believe, in the long run. That and a bunch of other little things. With some luck, you will find your recipe. Combine the good people around you, their support, the stuff parents taught you, the things you read elsewhere, and with some practice, you just might find yourself one day wondering how far you have traveled from where you are at now.

The 8 Habits of a 10X Coder

Hello everybody, happy Friday! Hope all is well.

In the last 12 months, I’ve written over 500 commits and probably way above 100k lines of code. In this document, I will share with you my secrets of being highly productive at software engineering. Specifically one area of software engineering – and that is coding. If you are a software engineer, and you want to print code faster than a Xerox machine, keep reading.

Heads up though! This post is totally opinionated. The rules here need not apply to everybody. It’s just what has worked for me and it’s just one of many ways to become a highly productive coder. I wrote this document in an imperative language, as if I’m talking directly to a less experienced version of myself. Don’t take it the wrong way 🙂 If you are that someone at the start of your career, you should also understand that Software Engineering != Coding. It’s much more than that. Coding is just a part of it. Do not underestimate other parts of the job, as the matter of fact, consider them just as critical.

1. Muscle-memory VIM

Once upon a time I joined a Big Tech Company, where there were no internal IDEs. The codebase there was a huge mono-repo. Millions of lines of code. No IDE at that time could meaningfully handle that volume of code. Like, if you tried to open it in Eclipse, it would take something like 1-2 hours for it to boot up. So, I did what a lot of other engineers did – I learned VIM. This is by far the best thing I did for myself. Writing code happens on a keyboard, and even the most rudimentary VIM knowledge makes one a beast at it.

You will need to learn VIM. Own it. Use it whenever you can, especially initially while you’re getting adjusted to the keyboard layout and shortcuts. It’s like learning how to walk again. The key thing about VIM is to be able to do almost all code editing things most efficiently and without using your mouse! Learn how to move around the page using a keyboard. How to select, copy, cut and paste things. How to reformat the code. How to jump paragraphs, words and letters. How to split windows. Jump in and out of methods. Search and replace.

Remember, using your mouse is a waste of time. To be a hyper productive engineer, you must optimize for keyboard use over the mouse. Be it through VIM, or through something else.

Finally, you don’t have to use the actual command line VIM. That’s not what I’m talking about. Feel free to use an IDE like IntelliJ or VSCode, but make sure you install a VIM plugin in it, such that you can still do all the awesome Keyboard things, without using the mouse. That’s the key – eliminate all mice!

2. Muscle-memory Git

This is the same whether you are using Git, Mercurial or something else. Fast commits, branching, squashing, resetting, rebasing, cherry-picking, pushing upstream, pulling downstream etc. In my .gitconfig file, I have about 20 different shortcuts. Things such as pull from the main branch, commit all modified files instantly with a default title, check out to another branch, delete all branches that are already pushed, show me a one line summary of the history log, etc. For anything that you repeat on a daily or weekly basis – you need to have in a two-three letter shortcut inside of the .gitconfig file. You don’t want to spend time typing “git checkout -b hello” when you can say “g cob hello”. These things accumulate over time, cause frustration, etc. Worth optimizing for.

3. Muscle-memory Shell

Regardless of whether you are going to be a Windows, GNU/Linux or Mac developer, you have to grok the Command Line. Learn how to write shell scripts. Automate all repetitive work using those scripts. This saves tons of energy and time.

4. Muscle-memory IDE

Modern (and even not so modern) IDEs are full of tricks that can help you save time. Things such as Organizing import statements in Java. Formatting the code. Introducing a new property. Running a test method. Searching across the whole project or workspace. Finding references (who is calling some method). Browsing the Type Hierarchy. Opening a terminal window. Selecting the current file in the Project Tree View, etc. You need to know that these tools exist and you need to know what their keyboard shortcut is at any time of the day and night. If some shortcuts are too hard to remember – reconfigure them. Save your mapping somewhere online so that you can reuse it if your computer crashes and such.

5. Speak the Language

A fluent natural language speaker rarely needs to stop and look up a word in a dictionary. Same is true for a fluent coder. To a fluent coder, code reads like a poem. All the syntax and built in essential libraries must be well known and understood. Things such as Async-Await in Python and Javascript, Executors in Java, or the C++ standard template library. You need to be able to read code fast. Granted, some code is complex and there is no way on earth that it can be understood without stopping and thinking about it for a while. That’s okay. I’m talking about the 99% of the rest of the code, which is basically converting one state object to another. You need to be able to breeze through those. It’s not possible to do this efficiently if you read through code and aren’t sure what it does.

Bottom line is – if you read through code, and aren’t sure what the syntax is – stop right there and invest in your future self and learn the syntax first, to a degree that you deem is necessary for the job.

6. Work the Framework

There are many abstractions and frameworks used in coding, which a lot of engineers avoid learning at all costs. Things such as Dependency Injection, Code Generation, Reflection, Immutables frameworks for various imperative languages, etc. Don’t skimp on those. I know it’s possible to understand how the thing works without understanding the framework – but if you are working on this thing – make sure you know the frameworks used well. A highly productive engineer must have a clear picture of not just the code they are reading, but also of the framework in which that code runs, the bigger picture.

7. X-Ray Code Vision

You will most likely get thrown into a new code base every few months or so. We change teams, or companies. A colleague goes MIA and you need to take over their project. Due to a reorg, your team inherits another team’s project and you’re the new lucky owner. A third party product is acquired and you are the point of contact for integration. A legacy system that you never paid attention to is getting deprecated and someone needs to go understand the damned thing and figure out how to shut it down safely while it’s processing terabytes of data every hour. “We are not in Kansas any more” kind of a situation there.

In all these situations, it helps to know how to quickly assess the new code base. And while it is intimidating no matter what, it’s absolutely doable and enjoyable. The trick which I recommend to you is two fold. One is to learn how to search the codebase. Oftentimes, we are dealing with hundreds of services and libraries and frameworks and there is simply no way to know them all. But you need to be comfortable to do an internal or external search for some method or class name and quickly understand what it does. The second thing is the Alice in Wonderland method that I use. Similar to an X-Ray, which goes through things, you need to be comfortable to dive deep into the uncharted territory – the code that’s unknown to you. Pick a random high level entry point, and then jump in. Look around, see something interesting, then jump into that. See how deep the rabbit hole goes. And then get out. Take some fresh air, do a breathing exercise, and repeat. Do a few of these “x-rays” and the idea of how the rest of the thing works will start to form.

8. Think like an Architect

Learn the architecture you are using. Learn about the services which your service depends on. Have a wider scope of understanding, go as far away as you can. If you are an AWS engineer, make sure you learn the essential services, such as SQS, SNS, DynamoDB, CloudFormation, Step Functions and also the domain specific ones such as Lambda, API Gateway, VPC, etc. You need to be able to recreate your service from scratch if it were to magically disappear. If you can’t do this, you have blind spots and that will impair you when you’re coding. Not understanding the big picture and how your piece of the puzzle fits in is detrimental to your productivity. Finally, become the architect.

Wrap up

That’s it. If you haven’t practiced these things before, adopting the habits will make you 10X more productive. I guarantee.

Turtles in Time #3 - Preview - Page 4 - The Technodrome Forums
“Leatherhead” from Teenage Mutant Ninja Turtles

The Coaching Habit

This post is inspired by a book I recently read, titled “The Coaching Habit” by Michael B. Stanier, and how it applied to my everyday life. It’s available on Amazon Kindle for $7.95.

Do you run into situations where it seems like someone just won’t listen to you? No? I’m happy for you! Yeah? Welcome to my world (and the rest of us). In the context of teamwork, I used to experience this frustrating feeling a lot. It used to make me feel misunderstood, ignored, unappreciated, etc. I would do everything to get rid of it. “Why don’t they just listen to me!”, I used to wonder. “We’d all be so much better off if you listened.”, I used to say. The irony is, it was me who needed to listen more carefully.

Enter this book on coaching. What is coaching?

Coaching is an act of asking questions, in order to navigate the discussion and learn more about the person across the table. It pairs well with active listening. Active listening means you aren’t there just to nod and mumble. It’s asking a lot of probing questions that will guide the other person to tell you everything you both need to know.

Communication is about establishing a link for exchanging information between two parties. What happens when you are not on the same page with someone? What I would do, usually, is double down on my own theories, and make the gap even wider. What would you do instead? I’ve arrived at a conclusion that in such situations I need to forget about my own agenda and focus entirely on understanding the other person. It takes serious willingness and commitment to do just that, but it will take you a long way.

Seven Chapters / Questions

So that being said, this book came quite handy to learning how to coach better, how to ask better questions to understand what the other person is saying. They are geared towards people who are coaching others, such as a manager-report or mentor-mentee situations. However, I found it quite applicable in other situations as well, including my own perils and frustrations with not being heard during team oriented debates. The book is organized in seven short chapters, each explaining how that question comes into play.

So, here they are, in order of appearance, what they mean in the context of coaching and how they applied in my own context of teamwork:

1. What’s on your mind?

The opening question. The author recommends asking this question to open up the discussion.

In the context of coaching in 1-1 sessions, the author describes two different situations. One is coaching for performance, which is the everyday, urgent matters of work. The other one is coaching for development, a more important, long term discussion that needs to happen in such a relationship.

In my own context, this is also a good question to stop myself from talking and let the other person express their point of view, uninterrupted.

2. What else?

The expansion. Author recommends following up with this question to get closer to the bottom line.

Most of us won’t immediately say what really bothers us or where we’re stuck at. This question can help get to it faster. It will help you skip over the mundane things and get to the important stuff.

Feel free to ask the question multiple times… and what else?

In my own context, this helps me get the most of the disagreement out in the open and laid out in front of me to understand.

3. What’s the real challenge here for you?

The Focusing question.

Once you’ve identified what’s really on the other person’s mind, asking this question will help you understand why it’s on their mind. Or what part of it is bothering them.

Feel free to ask the question multiple times here as well… what else is a real challenge for you?

In my own context, this question helps me get to the point of the disagreement. What’s at the core of the problem. Usually there will be one point of disagreement, where perhaps I made a mistake in my own thinking, which caused all the other points of disagreements. Asking this question and identifying that point together can help us both reach an agreement, by changing either of our opinions. Personally, I care only that we do the right thing, I don’t care who’s ideas win.

Stick to “what”

The author strongly recommends not drilling down on people with “whys”. They put people on the defensive side. They feel attacked. There’s a place for this question, coaching is not one of them. Besides, do you really need to have the backstory? Stick to “what”.

4. What do you want?

Author says there is a big difference between wants (tactical) and needs (core). We are more likely to talk about the wants, that get our needs satisfied, without directly revealing what our needs are. Your job as a coach is to understand the need behind the want. It will help you get the other person what they need, sometimes even without giving them what they want.

In my own context, I like to ask this question as “what is it that we want?”, as we’re working as a team on the same problem. If we’re coming to this discussion with opposite wants (I want it good enough and simple vs I want it great and elaborate), then perhaps that’s the real discussion we need to have first. Here I find it useful to acknowledge both our ideas are good in their own respective contexts, and that we’ve made progress towards a unanimous decision.

5. How can I help?

Great question that will help identify if the other person needs something from you. Author recommends guiding the other person to solve the problem for themselves, by asking more questions.

6. If I’m saying yes to this, what am I saying no to? Strategic question.

The author mentions five other strategic questions that should be considered before you jump into lending a hand to someone and spending your time on something that might distract you from something more important.

7. What was most useful for you? Repetition is the mother of learning.

Finally, at the end of each session and beginning of next one, author recommends reflecting on the past discussion as a way to hack your brain into remembering it better. Apparently, when we recollect our thoughts, our brain is more likely to put them in a long-term memory, and they are less likely to disappear. Therefore this blog post. Yup.

Meet Luka

Coffee shop in Novi Sad, Serbia. My wife Jelena, my best man Luka and I sit at one of the corner tables. It’s sunny outside. Quite beautiful weather for this time of the year. Jelena is reading the “How not to give a F**k” by Mark Manson, while Luka is texting on the phone, nervous about getting something to eat. We’re all excited about this interview. Luka’s also excited about his food. While we’re waiting, I’m happily jolting down a list of questions I’d like to ask.

Half an hour later…

Me: First of all, I’d like to thank you for accepting this invitation to do an interview! Tell us for starters, how are you feeling right now?

Luka: Currently I feel relaxed, well fed and I’m enjoying the time with my friends. So, awesome! 🙂

Smiles all around. We sure as hell don’t know what we’re doing here, but we’re still going to do it.

Me: In a few words, how’d you describe yourself to our readers, what’s your story?

Luka: I’m just a regular normal guy. A guy who has recently learned how to enjoy his little normal life, how to work for things that are dear and close to his heart. That’s what makes me me, right now.

I feel humbled by Luka’s modesty.

Me: Tell us more about this recent development – learning about how to live your life and what you care about the most?

Luka: I had been studying a lot recently, maybe even too much. Every moment I’ve spent on that. Everywhere I went. I could be in a bus, college, a dance club – didn’t matter – I’d read about JavaScript, React, GraphQL… It was intense. So I started cutting down on that. I’ve shifted my focus from programming to living, such as my emotional well-being. I spend a lot more time with my good friends. That makes me a lot happier than doing just work. It doesn’t come easy. It’s a struggle. Unlike technical knowledge, these things depend on other people as much as on you. It’s hard and exciting at the same time!

Me: How did it get to this point?

Luka: I wasn’t very ambitious about work before. The turning point in my life was when I became a father. I realized I had to do more, not just because of myself, or money, but because of my child. My family became my imperative. I felt the need to take responsibility. I started appreciating constructivism, being productive and such things. And I started surrounding myself with such people.

Me: and then?

Luka: Then I found programming. Fell in love with it. Too much, some might say. And now, I’m trying to strike a balance. Private life and work life. I’ve cut down a lot on the work front, but I think that’s okay. Something has to give, you can’t have it all. And I don’t have to be the best programmer in the world. But I can be a good one and live a fulfilling life. I’ve always cared about being social and my spirituality, but there was a period for about 4 years of my life where I spent my time thinking just about work. That period is over for me. Nowadays, I have more time to devote to myself and people around me.

Me: Woah, so you went from no work, to too much work, and just recently you’ve reached balance… I’m glad you’re taking care of it, such an important thing to do…

Luka nods. I give him credit for doing a great job at telling his story. Welp, I even give myself some credit for doing this for the first time… I read my next question.

Me: We met in 2016 while working on Mekice. How much do you remember about it?

Luka: So, this is how it happened for me… I was in my second year of college back then. I’d studied for 20 hours straight, sometimes. I was working on an Android app. In my time breaks from work, I’d check my Facebook feed…

Me: And that’s when you saw my post, I guess?

Luka: Well, yeah, but before we go into that… I loved psychology. Because I had my own problems, I thought I could help myself by studying it. So about 2-3 years before college, I’ve read about it intensively. The old guys, such as Freud, then some motivational books, such as Sharma, then I went into philosophy, such as Nietzsche. I spent a lot of time on that.

And then I saw your post. I had no idea who you are. First thing I noticed was that the project is about psychology. I also remember seeing the “Hi from California” in it. I’ve never dreamt about California. Just saw it as something serious. In Serbia I wouldn’t trust no one with this project. That attracted me. Hey, great, I thought. Somebody is looking for volunteers to work on psychology. I had to be a part of that story. That was interesting. It changed my life forever.

Me: It changed your life… care to share how?

Luka: You mean a lot to me as a friend. Somehow, whenever we talk I learn something new. I live better materially, but also spiritually. Before I thought it’s all about money and cars, now I have a balance between that and other stuff. I’ve taken a breadth of new interests. Not just because of you, I have other friends who have helped me in this way. Friends are the best thing ever 🙂

The feeling is mutual, my friend.

Me: Professionally, you are a JavaScript engineer. Tell us more, how did you choose this vocation?

Luka: We used to do PHP before this NodeJS craziness started. News arrive a bit late in Serbia. We’ve heard about NodeJS a couple years late too late. We had no resources where we could more. I had talked with some people from one of the Belgrade’s universities about it. They were interested in teaching it. That seemed interesting. But simply I thought I can’t handle that. I was thinking, let’s just do PHP, you know, whatever.

Me: So you heard of it, but it didn’t stick. What happened then?

Luka: Then, we talked for the first time, and you gave me a brain dump about this NodeJS stack. First of all, I’ve never heard about 20 new things in a single talk. I felt bombarded by your ideas. Then I felt ecstatic because I had so much to learn. I love learning. I also had a feeling these things are more advanced. In the future these things will be more applicable, I thought. It will be useful in a business sense. It has a future. I felt thrilled. And then also there was the product – psychology. Complete happiness!

As I write Luka’s comments, I start feeling this might come off as a self-promotion of some sort. I tell him to focus on himself, in my self-defense. Doesn’t come off as genuine, I think… welp, I give myself a break and continue.

Me: So you started with NodeJS while working on Mekice. Fast forward almost three years, you’ve moved on to work on various React and React Native applications. What is it like to be a JavaScript engineer in Belgrade, Serbia now? What kind of opportunities do you have? What kind of challenges do you face?

Luka: It’s an interesting thing, being a JavaScript engineer in Belgrade. It’s unusual. Java and PHP are the most popular programming languages here. Rarely I hear about people working on NodeJS and React, especially on the backend side of it. Frontend tech is getting more popular lately, but Node as a backend is not so much. By the way, React is killing Angular. It’s 10 to 1 in popularity. It’s great.

Now, speaking of opportunities, there’s plenty of them. Not that many people know how to work with this, and there is a huge demand for it. Employers are very motivating and they are hiring…

I also have an opportunity to learn new things. We just bought some tutorials for progressive web apps, and that Google’s thing – AMP. At the same time, I’m learning about PureScript. Continuous learning and development is crucial. We have to keep up.

Speaking of challenges, momentarily, I don’t have many. Really don’t know what to say. Nothing serious. No stress. Rarely. The most common and the biggest challenge is finding a company that pays regularly, and legally, with all the social benefits and stuff.

Me: Ah, the “advanced” business practices of ours! And go JavaScript! Let’s take a turn here… Other than programming, you’re quite a fan of trap music. How did this start? What do you like about it?

Luka: I love all music. Trap and rap I do since like forever. They are the same genre for me. I’ve been working with music since I was 8… well, don’t want to lie, perhaps 11 years old. Whatever I did, whatever job, situation etc.; one thing has been given: I will make music in the evening. I actually consider myself a hip-hop artist. More than programmer, taxi driver or anything for that matter.

Me: I also hear you are working on a song! Are there any other hobbies we’re not aware of?

Luka: I’d love to exercise more. Would love to make it a habit. I believe I will start next month. I start and stop oftentimes. I’d like to make it a long term hobby.

I think about my garage gym. The most workout I got out of it is when I assembled it. I feel for Luka’s lack of sustained motivation, when it comes to exercising.

Me: Your life hasn’t always been made of “milk and honey” as we like to say. What defined you who you are today?

Luka pauses at this moment. He thinks carefully. I hear a “huh” coming out…

Luka: The birth of my child, as I said. I used to be way too much into clubbing and partying, and selfish. But this moment changed me. All of a sudden I felt sad about my current situation, of who I am. I felt bad that I didn’t do as much as I could. I felt horrible… It lasted for a year or two. And then I found something greater to live for. I didn’t give up, I started fighting for it. I stopped caring just about my pleasure, and started thinking about other people. That’s the biggest victory of my life.

Me: Any lessons you learned from that experience that you’d like to share?

Luka: I think people should learn to delay their pleasures. To find things they love to do. To devote themselves to them. To learn to give up on things that don’t really matter, you know, short term gratification and such. In the end, they will meet their goals. For me, I used to think party comes first, as in, first I’d want to go for 20 days on Ibiza, then I would do something constructive. Actually, things are different. Hard work comes first, then Ibiza 🙂 Unfortunately, I lot of people don’t realize that. I was very lucky.

Thinking about Ibiza… Jelena and I almost spent our honeymoon there last year. We look at each other and smile.

Me: You’re also a very versatile person. I know you’ve worked as a taxi driver, then in the textile industry, you also had your own start up… what did you learn from all of those?

Luka: I can’t say I’ve learned any special skills from any of these jobs that I could brag about right now. I did learn, however, how it feels when you think you don’t have any future ahead of you. Feeling hopeless. Back then, the best that could happen to me is to have a customer I’d drive for 30 kilometers instead of just 3. The best thing I could hope for is that some day I would be driving a better car. You can’t go further.

We nod at each other. Luka sways his head to the right side, as if to signal it wasn’t easy for him back then.

I just realized that I didn’t want to do that any more. I figured you won’t get anything easily. Now when I reflect, I wouldn’t even want that (getting things the easy way). The best successes are the ones that you earn. If someone told me 5 years ago, that I will be working and fighting to reach my goals, I wouldn’t believe it. Either I should have everything, or nothing – I’d rather be wasting my time, than struggle trying to achieve a normal life, that’s what I thought.

Now, I find it more exciting to have a 1000 EUR salary, then 2000, then 3000, than to make an app for 1 billion dollars and call it done for life. I love working step by step. It gives me continuous satisfaction.

Me: Progress?

Luka: Exactly, feeling the progress.

Me: This is a cheesy question, but I had to ask – looking backwards, if you could go back in time, with all the knowledge you have now, would you do that, or would you rather have any wish come true right now, and why so?

Luka pauses here… he smiles.

Luka: I’d go back and program a lot. You ask me why? I don’t know. I had a lot of free time. I wish I used it more to develop myself. Math, physics, chemistry, biology.

Me: … and looking forward, where do you see yourself in 5 years?

Luka: In a business sense, I see myself as an algorithm guy, someone who knows math better. Privately, I can’t predict, I don’t know. Perhaps I’d like to have another kid. No vision right now, I’m still searching for it.

Me: I’d like to thank you Luka for your time and wish you all the best in finding your vision. Any kind of a message you would like to send to our readers?

Luka: I genuinely want your readers to feel well and to be content and happy, with themselves. Work on yourself, invest in yourself. Spread the love around you. Positive vibes. And fight for your own goals.

I look outside, and it’s raining again…

That’s it folks, thanks to Luka for sharing his amazing story with us, it really is a gift! Hope all is well and see ya next week!

Introspection via the “Who am I” document

At any point in time during your career, the bottleneck to your growth and development can be a lack of insight and self-awareness of who you are and what makes you perform the best. Read more to learn about the process of introspection using the “Who am I” document.

Who am I

To start with, this is something I learned while working with my self-awareness mentor. Dear L.C. taught me this great format for introspection, a “living document” that you should be constantly reviewing, getting feedback on and so on. Down below there is an excerpt from my “Who am I” document and how to write it.

How to write it?

You write this document bottom up. Start with your workflow, something that’s easiest to observe. Write down how you wake up, how much you work, when do you eat, who do you hang out with and so on. Whatever is relevant for you.

When you fill out that section, move one section up. Write that one in, using the insight you’ve gained from your previous section. Remember – it’s actually good if it sounds repetitive and obvious. There should be a strong causality and correlation between all sections. Otherwise you might be lying to yourself (not necessarily, but, you could be).

So, Who am I?

Here it is – the outline for this document and some examples of what you could write in for your document.

1. My purpose

This is the top section, the one you will write the very last, after many iterations on your doc. Feel free to keep it empty for some time. The purpose will eventually reveal itself.

To be a super awesome technical leader at solving hard problems, while inspiring people around me.

2. My core beliefs

A core belief is one that’s like a constant in your world. Something you can’t part with so easily. It defines who you are, what else you believe in, what you care about the most, who you want to become and much more. They are not always perfect and healthiest for you, so have compassion for yourself.

Productivity: I have to be productive to feel happy with myself.

Challenge: I have to be challenged to feel like I’m doing something that matters.

Social: I am a social creature and I can’t live without having great social interactions.

3. My leadership values

How do your beliefs and values translate to your work environment? Each great company nowadays has a strong culture and a set of leadership values that you can and do identify with. Find what resonates with you.

Deliver Results: Leaders deliver results in timely fashion.

Dive Deep: Leaders go to the heart of the problem. No task is beneath them.

Learn and be Curious: Leaders are constantly working on improving themselves.

Earn Trust: Leaders treat others respectfully.

4. My strengths

Strengths and weaknesses stem from your previous sections. They are like psychological archetypes – double edged swords, two sides of the same coin.

Fast: My speed of execution is amazing. Once I get an idea of how to solve a challenging problem, there is no stopping me.

Technical knowledge: I have what it takes to solve hard problems and I’m not afraid to learn new things.

Unselfish: I’m always happy to share my knowledge and help others succeed.

5. My weaknesses

Here I write not just what my weaknesses are, but what do I have to do in order to compensate for them.

Rushy: I can sometimes rush too hard to get a problem out of the way, making others around me feel uncomfortable about the associated risks. I have to make sure people have their concerns addressed properly first.

Trust: Since I love problem solving so much, sometimes I can have issues with trusting other people with work – delegation – will they do a good job at it? Therefore, I have to let go more often than I would instinctively, but perhaps offer my help in reviewing the work or mentorship in case they get stuck.

Gullible: I will go out of my way to help others and sometimes that makes me vulnerable to exploitation. I have to ask probing questions to defend from this.

6. My passions

What gives you butterflies? What is that thing you love to do, that others might call just work, but you experience as enjoyment?

Excellence: I’m passionate about being excellent – especially in the software development world and in my hobbies. This makes it possible to be fast and solve challenging problems.

Psychology: My favorite hobby is learning and practicing good mental hygiene.

Learning and teaching: I love learning new things and then sharing my knowledge, especially in areas such as music, psychology, leadership and computer science.

7. My operating principles

Principles stem from values. This is how you prefer to do your job. For example, if you value integrity, your principle might be “Do everything by the law” and such.

Move fast: I like to execute fast. I love competing with myself. Also, done is better than perfect.

Kaizen: I continuously learn new things and improve my existing self by examining my past work and mistakes.

Soft-skills: I pay attention to how I treat others around me and how I can make it a comfortable experience.

8. My values

Values are things you hold dear to your heart. If someone were to negotiate a work environment with you, these are the things that would be the hardest to compromise on.

Speed: I don’t like when things move slow, hence I’ll do whatever is reasonable to speed them up.

Growth: Learning is very important to me, from the earliest stages of my life. Knowledge is happiness.

People: I treasure people around me and our relationships, and I can’t do work in a way that might bring them harm.

9. My workflow

Start with this section. Describe what does your day look like.

Productivity bursts: I don’t do a lot throughout the whole day, but every day I find some time to sit down, get in the zone and do some amazingly productive work.

Learner and teacher: I look for opportunities to help others and to learn something new, every day.

Socialize: Colleagues and friends? Yes please. Let’s have a beer buddy. I love to take a break with my peeps at work and talk about the non-work related stuff.

Iterating on the document

When you start writing this document, you embark on a journey. You won’t get it “right” from the start. It will never be “done”. Keep going up and down the document. As you start moving bottom up, you will occasionally see that something you wrote in your bottom section, say “workflow” for example, is not so crucial as you thought. Sometimes you will discover something in the middle, say a “leadership value” you care about, and you will see that it’s actually not reflected in any way with your values. So you think a bit about those and edit one or the other (or both) to make them “sync” with each other. Remember, the journey is more important than the destination.

Reviewing the document

Once you are happy with your doc, find a good friend of yours who knows you better than you know yourself, and ask them to read your doc. Ask for their opinion. Does it sound like you? Would they add or change anything?

Keep it alive

Review the doc from time to time (once a quarter or a year) and tweak it. We all change with time, after all.

Conclusion

Thank you for taking your valuable time to read my article! I hope you will find this exercise as exciting, revealing and rewarding as I have. And thanks to my awesome mentor L.C. for sharing this with me and allowing me to share it with you.

Four Communication Types

During my career in the Silicon Valley, I’ve mentored and coached dozens of people, without ever having a formal training on it. Last year, I attended the Berkeley High Impact Leadership course and I finally learned a good theoretical background behind these processes. In this article, I will be sharing the secret recipe with you!

After reading, you should know more about how to express empathy in your relationships, as well as the basics of playing the four basic role archetypes.

Empathy

First of all, I’d like to emphasize the importance of empathy in your work relationships. What is empathy? The best explanation I’ve heard over the years is that it basically means to be able to walk in other person’s shoes. To imagine you were them. How would you feel?

For those that like an instruction manual to everything, like myself, here’s a quick trick. There are two types of empathy according to the cognitive psychologist Dr David Burns: thought and feeling empathy.

Thought empathy is simply the act of summarizing what you’ve heard from the other person.

Feeling empathy is simply the act of noticing how the other person is probably feeling and letting them know you are aware of their emotions.

So let’s take an example. Say your coworker Bob comes to you with a following problem:

Bob: That meeting went horribly. We’re two months behind on our schedule and our director demands we meet the deadline, which is only four months ahead of us! I don’t know what to do!

You: Sounds like you are behind on your project (thought empathy). You must be under a lot of stress (feeling empathy).

Bob: etc.

This conversation pattern can occur for as long as Bob needs to talk with you. Pay attention to Bob’s words and body language, they will make empathizing with him that much simpler.

Support Role

What we’ve seen above is also called the support role. When you choose to play a support role in your work relationship, your job is to simply empathize with your coworker and simply make them feel heard. Is this useful? Oftentimes, this is exactly what people need, especially when under a lot of stress. Giving premature advice or asking too many questions might do more harm than good.

The main quality of the support role is that it’s full of empathy, but not much on telling the other person what to do, nor asking a lot about it. Let’s put those two on a graph:

Fig. 1) Support has “low tell” and “low ask”.

Who to support: Ask yourself – do I know this person well enough? If the answer is no, probably the best course of action is the support role.

Coaching Role

So what do we call it when you start asking questions, inquiring? For example:

Bob: That meeting went horribly. We’re two months behind on our schedule and our director demands we meet the deadline, which is only four months ahead of us! I don’t know what to do!

You: Sounds like you are behind on your project (thought empathy). You must be under a lot of stress (feeling empathy). What do you plan to do about it (inquiry)?

Bob: etc.

That’s coaching in a nutshell. The main pattern is:

  1. Listen: pay attention to what the other person is saying and what does their body language reveal.
  2. Empathize: show that you’ve heard the other person by empathizing with them using thought and/or feeling empathy.
  3. Ask: using open-ended questions, help the other person think about the problem they are having and help them reach the solution on their own!
  4. Go to step 1.

Most importantly, when coaching, do not ask suggestive questions. Then you aren’t a coach. Ask open-ended questions. Questions that cannot be answered by “yes” or “no” and such. Instead of asking “are you going to do X about it”, ask “what are you doing to do about it”. Let the other person think about the solution, your job as a coach is to guide them in their thinking. Keep them on track.

Not having to give any advice, coaching is very useful when you feel that the other person is far more capable of solving the problem for themselves than you are.

Fig. 2) Coach has “low tell” and “high ask”.

Whom to coach: Ask yourself, do I believe this person can resolve the problem at their own? If yes, assume the coach role.

Advisory Role

Let’s take an opposite example. What happens when you know more about the problem your colleague or friend is having and you want to “jump right into it” and help them succeed? In this case, you are playing the role of an adviser. You aren’t asking many questions, but you do tell a lot. Make sure you are invited and welcome to play this role, before you do. Playing an adviser is a dangerous one!

Fig. 3) Adviser has “high tell” and “low ask”.

Whom to advise: This one is best to do when you are directly asked for an advice, such as when being a consultant. Otherwise, ask yourself, did this person ask for my advice?

Mentor Role

Finally, being the mentor is my favorite relationship type. In this role, you are going to ask questions and give advice, you will empathize, support, coach and advise, all at the same time.

Fig. 4) Mentor has “high tell” and “high ask”.

Whom to mentor: Does this person need both coaching and advising? See above. Make sure the person wants to be mentored.

The other side of the archetypes

Finally, when playing all of these roles, you have to pay attention to how your participation is received on the other end. Just knowing these “recipes” won’t make you the best coach or mentor in the world, right? Trying to be a supportive person can render you seem absent or useless. Being too much of a mentor can make you seem like a micro-manager, and so on. So here’s an example of what could happen if things go wrong:

Fig. 5) The negative sides of the four communication roles: Micro-Manager, Dictator, Absent and Nuisance.

Summary

Alright, hope you had a fun time reading the article. Remember – listen, repeat, then ask for more or give advice if you have a good one. Remember to use open-ended questions. Choose the right role for the situation. Be mindful – focus on the other person, forget about yourself.

Thanks for reading thus far and see you next week.

Redux for the Perplexed

I was working at Facebook in 2015, I believe, when I asked my manager for a temporary transfer to a team that was working with React and Flux. Back then, looking at this new pattern, I was somewhere in between of being amazed and perplexed. Like, what is this thing, just why? Nowadays fewer projects use Flux since the invention of Redux, which is pretty similar to it, just simpler. If you feel the same way about it the way I felt about Flux, this article is written for you, to aid your entry into the world of this amazing way of application state management.

Intro

At its core, Redux is just a simple little library, maybe call it a design pattern, which will help you manage your application’s state. Things such as values inputted in a form, or the list of names shown in a table. It does this by storing all of the state into one giant, nested object. The state object is immutable, the view layer of your application cannot directly alter the model of the application, nor can one part of the model update another part of the model. All updates of the model are happening at a neatly collocated space, called the reducer function, and it always happens in a unidirectional, so called, dispatch cycle. If that all makes sense – congrats, you need not necessarily read any further. Check out the official Redux documentation and jump right into it. If however, you are still perplexed (like I was), keep reading…

Comparison with MVC

Tell me, do you know what Model-View-Controller a.k.a. MVC is? Think about it then keep reading.

To my understanding, it consists of (obviously) three things:

  1. Something about having an object which holds raw data, the primitives, also known as the model.
  2. Another thing which shows the model to the user, known as the view.
  3. Controller, which reacts to user’s actions and updates the model, which then updates the view via a set of listeners.

In MVC, data flows around from model to view, from view to controller, then from controller to model. And back again. In addition to that, one model object can subscribe to another model object, pretty much everyone can read, subscribe and alter the model, and so on. This can lead to a messy event propagation through your application state, including infinite loops and whatnot. Very complex to debug.

Redux solves the same problem as MVC does, except that it avoids the infinite loops and “everyone can update the model however they want” part. It’s concerned only with the model, and partially with the controller – the part where controller updates the model. It also makes sure that each state is well contained – just like a React component is – nothing outside of it can affect how it manages it’s data. So what does it have instead?

  1. It has a state, which is roughly equivalent to the MVC model – a plain, preferably immutable, JavaScript object.
  2. It has actions (similar to a controller), which describe events in the system that should trigger model updates.
  3. Finally, there is the reducer (also similar to a controller), which is simply a pure function that explains how an action affects the state.

The coupling between the model and model controller is much tighter here. This makes it much easier to encapsulate (in code) where and how does model change with each action. You no longer can have one model subscribe to another and trigger an avalanche of chained updates, including the dreaded infinite loop.

Before jumping into more theory, let’s take a look at some code…

Writing a reducer using Ducks

There are actually multiple styles around regarding how do you write Redux code. The one I’ll present here is the ducks format, which is rather collocated form of writing Redux. A “duck” is a file which contains three things – action types, action creators and a reducer:


// ./app/ducks/document.js

// 1) Action types usually are stored in a constant
// Prefixed by the Duck name.

const DOCUMENT_CHANGE_TITLE = 'document/changeTitle';

// 2) Action creator is a function that returns an action.

export function changeTitle(newTitle) {

  return {
    type: DOCUMENT_CHANGE_TITLE,
    newTitle,
  };
}

// 3) the meat of the duck - reducer.
const INITIAL_STATE = { 
  title: '',
};

export default function documentReducer(
  state = INITIAL_STATE,
  action, 
) {

  // Check whether this action affects our reducer.
  switch (action.type) {
    // If the action is one of our own, then yes.
    case DOCUMENT_CHANGE_TITLE:
      return {
        ...state,
        title: action.newTitle,
      };
    // Otherwise we don't want to change the state.
    default:
      return state;
  }
}

Alright, make sure to read the snippet above and understand as much as you can.

To put the above code into words – by Redux design – whenever something happens in your app (user enters a query, clicks a button etc) – you will fire off, or dispatch, an “action”. More about this later. Action is just an object with the type property. This action will then be sent to all the reducers. That’s important to notice. This is why our reducer has the switch statement – to filter out all other actions which are not meant for this reducer.

To go into details, let’s look at each of the parts individually:

  1. Here we specify which action types exist in this ducks file. Our has only one – the DOCUMENT_CHANGE_TITLE. Usually, they are prefixed with the duck name (“document”, you can also see this in the duck name – document.js) and suffixed by the action purpose (“change”, as this action is about updating a value) and target (“title”, as we want to change the title). By default, this constant is not exposed, but it can be made so if we desire other reducers to be able to react to this action event as well.
  2. The action creator is an exposed function. This is what external components (e.g. React) will use to communicate their intention with the reducer. This is how you trigger state updates. Simplest action creators just return a simple object with a type property, which hold one of the values from the action type constants. These functions don’t have side-effects – they don’t change anything outside of their scope (or at least not until they have been dispatched, in case of redux-thunk library, which will is an extension of Redux).
  3. Reducer is the glue which combines all different action types into one state object. It’s literally a reducer, in the functional programming sense, taking the previous state and next action event, and reduces them to the next state. It is important to notice here that the input state object is not modified – instead it is cloned into a new object by using the spread syntax (three dots).

Redux store

Once we have all these reducers / ducks written out, we need to combine them into a store.


// ./app/store.js

// 1. Import redux.
import { 
  createStore,
  combineReducers,
} from "redux";

// 2. Import our ducks
// The first one is our example above,
// others are left to your imagination.
import document from './ducks/document';
import notifications from './ducks/notifications';
import session from './ducks/session';

// 3. Export a store creating function.
export default function createMyStore() {
  return createStore(
    combineReducers({
      document,
      notifications,
      session,
    })
  );
}

Again, make sure you read and understood as much as you can.

To put the above code into simple words, we’ve just created a function that will help us create that large, nested, state/model object – also known as the store. We do this by taking a bunch of reducers and combining them into one. The store object has two things – not mentioned above – the getState and dispatch methods. Calling getState will produce an object that has three keys – title, content and notifications, each of which will hold its corresponding state object as described by each reducer.

So if anyone wanted to know what the current title is, they would have to access store.getState().document.title. First layer of that access pattern is always calling the store’s getState() method. Second layer is the reducer’s name – document. Everything else remaining is accessing the desired property from our document state – title. This is the case when using combineReducers such as above.

To go into details, let’s examine each of the steps:

  1. This basic example includes importing the createStore function and combineReducers function from the Redux library. There are others, for more advanced examples, such as applyMiddleware and compose etc. Thing is, they are all much simpler to understand once you know the basics. We will use these two functions later.
  2. Now we import our ducks / reducer functions. Each duck will later become part of the store, by using the Redux functions mentioned above.
  3. Meat of the store creation is combining the createStore and combineReducers functions. Former one creates the store – an object which has the getState method, for fetching the current state, and a dispatch method, for firing off new action events into the store’s reducers. Since createStore works with a single reducer only, we need to use the combineReducers method to combine our multiple reducers into one big reducer. Effectively in the store’s state, it will produce an object that will be keyed by the reducer name, and a value which will come from the reducer’s state.

Dispatch cycle

Finally, how does one communicate with Redux? When you need to render your view, the data is then fetched from the store using the getState method. When a user does something on the app that should affect the state, you will communicate with the store through it’s dispatch method. Usually, projects will initialize their store at the application bootstrap and keep it in a singleton. Then they will use a wrapper library, like react-redux to “connect” their components with the store (both dispatch and getState), so that it removes some boilerplate. But without going into depth of such libraries for different UI frameworks, in it’s core, this is what happens:


// ./app/application.js

import createMyStore from './store';
import { documentChangeTitle } from './ducks/document';
 
// 1. Initialize the store somewhere in your code, once:

const store = createMyStore();

// 2. Dispatch an action from your controller:

store.dispatch(documentChangeTitle('Hello World'));

// 3. Obtain the new state, from your view:

console.log(store.getState().document.title);

The example above has three parts, which are usually not all in the same file in a real world application.

  1. Initializing the store is as simple as calling the store creator function. You keep this store somewhere in a singleton so that the entire app can access it. Preferably you will use your framework’s extension library to manage the store, such as react-redux.
  2. Altering the state is possible only through the dispatch method. You basically construct your action object using an action creator (documentChangeTitle in this case), describing what’s changing, and then let the store know about it using the dispatch method. This will trigger all reducers in your application. Only the reducers which care about this action (document.js) will react to it – and as a result the internal state of the store will change to reflect this action.
  3. Getting the store’s state (model) is as simple as calling getState(). Then you navigate through the returned object’s layers to find the value you need. This is something an MVC view would do, most commonly.

The dispatch cycle is basically this pattern of dispatch, getState, dispatch, getState… There is no other way to change the store’s state, nor to retrieve it, than through these two methods. This is what makes the data neatly encapsulated and unidirectional. The actions flow from your application’s event handlers to the reducers, which update the store’s state, which causes the presentation layer to change, and all over again.

Conclusion

Hopefully by now you have a better idea on what Redux is, how it compares with MVC, what does it generally look like and you are no longer perplexed.

Finally, if you have any questions or doubts about Redux, I highly recommend going through the official Redux documents to expand on your knowledge at https://redux.js.org/api as well as feel free to shoot me an email at sreckotoroman@gmail.com

Solving a Bad Scrum (TM)

In the programming world, Scrum is known as a development process technique – a way of organizing how work is done! There are plenty of articles out there, but here’s something of my own perspective on things.

I’ve been a Certified Scrum Master by cPrime since 2015. I’ve worked for multiple scrum teams in different companies. Here are the common pitfalls I’ve seen in my experience, and how to avoid them.

Let’s kick off with a…

NFL Ref Meeting - stand up update: yesterday... ... all my troubles seemed so far away...

Too long of a daily stand up

Problem: Some folks like to run daily stand up meetings that last far too long – sometimes more than an hour. It happens, believe me, I’ve seen it. People get caught up in problem solving, doing a little bit of design discussions, a little bit of project planning, few debates about favorite coding environments and so on. Poof! One hour gone. That’s, on an 8 person team, about one engineer worth of time lost every day. Well, truth be told, some of these discussions can be productive, still, is the trade-off right?

Solution: First of all, analyze what’s causing it – what is the reason behind the long stand up. Is it the lack of awareness in the team that stand-ups are more productive if kept quick? Is it the Scrum Master, Product Owner or the Manager who likes to keep tabs on everything? Is it that there is a lot going on and people need to discuss a lot of things that are on their minds? Once you’ve done that, work with the team to show how much that reason is costing them – in time and efficiency. Offer to run a different kind of a stand up – one where (as suggested by pretty much everyone) people quickly just acknowledge each other on three things – what has been done last day, what is being worked on today, and are there any blockers. One minute per person, tops! Break up after the quick meeting and discuss anything you have with individuals, if needed. Congratulations, you’ve just saved your team tons of productivity.

No stand up

Problem: Some folks run “Scrum”, but without a daily stand up. Perhaps they don’t have stand ups at all, or they run a weekly stand up, or something else. This is far better than the previous problem, of having too long of a stand up, but is it good? Stand-ups are like brushing your teeth – it’s a morning routine, good for your team’s health. Now, I don’t have any data to back this up, so you will excuse my “proof-by-common-sense” here I hope, but, having a stand up is a great way to make your team feel like a team. People make eye contact, everyone gets a chance to speak up, everyone gets heard, positive energy is exchanged, camaraderie is built etc. That’s what a good daily stand up does for your team. It’s a useful, affordable routine, when done properly – quickly and consistently.

Solution: What is the reason behind not having a stand up? Does the team feel negatively toward meeting every day? Do they feel there aren’t enough many updates to be shared every day? Is it that everyone is working on a separate track? Perhaps you don’t need it after all? If you think otherwise, and would like to fix this problem, try offering to your manager to talk to everyone on the team and find out about their sentiment on daily stand ups. Figure out where you’re at. Address the concerns using some of the values mentioned above and propose a solution to your team. Offer to run a daily stand up for one week, and see whether the team’s sentiment changes.

Next we have…

Rent Is Too Damn High - our product backlog is too damn long!

Humongous product backlog

Problem: Your team’s backlog has several hundred stories in it, nobody knows what lurks in there and it just keeps growing (i.e. new stories are added faster than old stories are being closed). It’s not prioritized ranked (because it’s impossible to do), half of the items are deprecated since last year and the rest is so poorly documented nobody understands what they are all about any more. Its purpose has come down to serving purely as an excuse of a backlog, something where you put stories and hopefully never have to look at them, ever.

Solution: Start fresh, unfortunately, is your best bet. With your next, fresh backlog, use the following recipe to make it end up not-like-your-old-backlog.

  1. Rename your existing backlog to Unplanned. That’s your graveyard of stories anyway, things that aren’t on your roadmap and who knows if they ever will.
  2. Create two additional folders for your stories: Planned (this is where you will build your fresh backlog) and New (this is where people add stories which are not refined yet).
  3. Keep your Planned backlog ranked, not prioritized, i.e. do not have “High”, “Medium” and “Low” stories. Rather, have them numbered, e.g. from 1 to N (the number of stories in the backlog).
  4. Limit it to ~50 stories, so that anyone, especially the Product Owner, can have at least some idea about what’s in there.
  5. Start by polling the stories you think you will be working on in the next 3 months, but no further than that. Sift through your old backlog, check with the team, managers etc. Put them into the New folder.
  6. Schedule a backlog grooming meeting. In this meeting, go over the New folder and make sure all stories are:
    1. Estimated – for example using Fibonacci’s complexity points. I prefer using 1 for anything that’s easy (relatively a day or less), don’t go more granular than that. The 1, 2 and 3 are “small” stories – workable by a single engineer in a single sprint – anything bigger than that either needs to be broken down (as the time comes for you to work on it), or it needs more than one engineer to work on it during the sprint. This is just an example of how to do this estimation, pick your poison.
    2. Formatted – the story beings with a customer in mind – As a <who?>, I want <what?> so that <why?>.
    3. Detailed – the story has acceptance criteria – basically think of it as a break down of requirements. Sometimes, it’s like objectives and key results. E.g. if the customer wants a new car, the acceptance criteria might contain that it must be fuel efficient, or that it must be black, etc. Don’t go overboard with this.
    4. Ranked – compared with the rest of the stories in your Planned backlog (which is initially empty), assign a number to it, from 1 to N. Fractions are okay when you are okay during the grooming meeting, but at the end of it, you should reorder all stories back from 1 to N (e.g. 1, 1.5, 2 becomes 1, 2, 3).
    5. Repeat and rinse weekly.
  7. Sprint planning? Pick your top stories from the backlog (more or less, things oftentimes changed since the last grooming meeting) and run back to work!

No backlog whatsoever

Problem: Some folks like to keep it informal. This is, again, not as much of a problem as keeping a bogus backlog around. Less overhead. Still, you are probably missing out on a good technique to keep everyone focused. You can’t answer things easily such as “when will this get done?” (assuming you are not going to do it right now), “what’s on your roadmap?” etc.

Solution: Figure out what’s the reason behind this. Lots of people have never seen a functioning backlog (check the previous situation and the award winning recipe). Perhaps people are “too busy”. Etc. Offer to create a backlog for the team and manage it for some time, and see whether it works.

Finally, with so many meetings (grooming, planning, daily, retrospective, demo), there’s one common problem of…

First World Problems - in a scrum meeting again and i forgot to bring my laptop

People are bored to death by your Scrum

Problem: Lots of people love to run meetings, and I can’t blame them for it (I’m one of them). It can be a fun, dynamic, fulfilling, and as one meme said, “excellent alternative to doing actual work”. Your hold your Scrum meetings, but you notice your team is on their phones, laptops, nobody is paying attention, everyone hates it, yada-yada-yada.

Solution: Fix yourself! The team is not at fault! Understand why do people prefer the alternative to listening to your meeting. Are you engaging with the audience enough? Do you ask questions, even rhetorical ones? Do you change your intonation when you speak? Is your meeting too long? Did you ever ask the team what they think? Does this meeting produce any value? Whatever you do – don’t keep your meetings longer than 45 minutes. Keep the last 15 for Q/A, or let folks off the hook early – everyone loves that. If you are in the position of leading these meetings – make it a priority that everyone else gets an equal chance to participate.

Thanks for reading thus far, please do share what other problems & solutions you’ve seen in Scrum teams and lastly, if you and your team really can’t stand doing Scrum, but you are doing it because everyone else does – the quick tip is – you don’t have to do Scrum – at all. And you are not alone in this. One of the people I admire the most in this world would agree with you – Erik Meijer:

Getting out of a broken Ubuntu 16.04 system after an upgrade

Hey just a short update with some quick notes about how I fixed my system after a broken upgrade from Ubuntu 15.10 to Ubuntu 16.04.

So here’s what happened. I own a System76 computer, which is supposed to be optimized for Linux and hardware compatible (which it is, and I thank the guys at System76 for that). Unfortunately, with the latest update, the latest series of Intel processors (Skylake, 6) coupled with Nvidia graphics is broken. All ending up in a broken installation with no way to remedy the problem.

Read this if you’re stuck: https://bugs.launchpad.net/oem-priority/+bug/1564156

Also read this: http://docs.system76.com/articles/upgrade

After that, my solution was to install a new Ubuntu system alongside so I can operate on the fixes from that, rather than booting from a Live CD. I’ll use this system to fix my broken system. Important: during the installation of the second system, make sure to enable a Wireless/Ethernet connection and enable Updates during the installation. Otherwise, you’ll just end up with another broken system.

After installing, the trick is to mount your old Linux installation, chroot into it, and then complete the upgrades/installation of System76 and NVIDIA drivers. Simply put, the list of my commands was:

 # mkdir /mnt/yo
 # mount /dev/sda1 /mnt/yo
 # mount --bind /proc /mnt/yo/proc
 # mount --bind /dev /mnt/yo/dev
 # mount --bind /etc/resolv.conf /mnt/yo/etc/resolv.conf
 # mount --bind /tmp /mnt/yo/tmp
 # chroot /mnt/yo
 # apt dist-upgrade -f
 # apt-add-repository ppa:system76-dev/stable
 # sudo apt update
 # sudo apt install system76-driver
 # sudo apt install system76-driver-nvidia

And that is it. Hope it helps. The best thing I got out of this is a realization on how amazing chroot is for fixing broken installations.

EDIT: I also had to upgrade my Nvidia drivers to be able to run GNOME3. http://askubuntu.com/questions/760934/graphics-issues-after-installing-ubuntu-16-04-with-nvidia-graphics