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