I'm Branko,
Bane [bǎːne] for short.

I love to solve other people's problems and make them happy. And I love to make software.I'm deeply interested in better way to work. We all spend third of our adult life working, and another third complaining about work. It doesn't has to be like that. I will also write about various resources that inspired me to make work work.

Blog

I write about things I do, things that inspire me. But to write, first step is to learn how to write. Bellow you can find my journey from nothing to wherever I am now.

Teaching myself to write - After chapter 1

Writing is tough. That's most important lesson from the chapter 1. I will break it down later in smaller pieces, but headline is that writing is hard work, not miracle skill acquired at birth. Luckily, it can be learned! Let's get to it. Chapter 1 covers:
- Simplicity - Every word has to serve a purpose in a sentence. I first wrote "Chapter 1 covers following", and then I removed word "following". It serves no purpose. It's obvious that something is following. Only way to properly achieve simplicity is to write, then rewrite, and then rewrite more. It's very difficult to avoid putting unnecessary words. Partially because trend is to sprinkle the sentences with bunch of words to appear important well read.
- Clutter - This is similar to previous point. It is widely used tactic in government announcements, to confuse the reader and appear official. One example from the book: what is wrong with simply saying "now" instead of "at this point in time"? Adding more words to a sentence simply because there is nothing more to be said is clutter.
- Style - This is, in my opinion, point that will take me the longest to improve. It's not something that can be quantified without enough written material. I will not pay much attention to this point for now.
- The Audience - Book says that you, the writer, should be the sole audience. This is complex topic that has two sides. First one is that the message and style should be personal, for writer. Second is that it does not mean that sloppy writing is allowed. If writer loses reader because of the sloppy writing, that is on the writer. If reader is not interested in the message, then it's perfectly fine to lose the reader. At least this is my understanding.
- Words - For non-native English speaker, this is going to be very slow process of expansion of vocabulary, and understanding right shades between the synonyms.
- Usage - Same as previous point, usage of the words and forms requires deep knowledge of the language. It will take me years to figure this out.My take on this is:
- Write, read aloud, and adjust until sentence and paragraph sounds good.
- My audience is international, not just native English speaking, so I will write for them same as I would like to read - to the point and without using complicated words.Now I'm going to write a short paragraph on serialisation of medicine in EU. I'm going to write first draft in one go, as I would normally. Then, I'm going to do one or two revisions, where I'm going to apply what I read in chapter 1. I'm still not going to pay attention to grammar. I'll use what I know for now.Falsified Medicines Directive in European Union
Falsified Medicines Directive (FMD) is legally biding directive in the EU created to protect public health. Reason for it is because certain percentage of medicine in circulation is counterfeit. It requires that all prescription medicine produced or imported in the EU have specific, unique code on the packaging for purpose of tracking and verification that medicine is genuine. Legal framework was in development since 2013, and as of February 2019 law is in force in almost all countries in EU. Some countries got extension period for adoption. In the beginning, when law kicked in, there were many issues with interconnected systems. Real world usage simply didn't match to the processes and procedures that are already in place in many companies. Therefore, many countries decided to go with soft launch. That means that use of the systems was mandatory, but errors were ignored, like before. That gave everyone time to polish out the issues.Rewrite
I think this is enough material to work with. I'm going to take 5 minute break, read the paragraph aloud, and start applying writing principles from Chapter 1. I know that this whole paragraph can be rewritten to sound better. That is not the purpose of the exercise. Step one is to apply Chapter 1 guidelines. Future chapters will be used to work on the message.Falsified Medicines Directive (FMD) is legally biding directive law in the EU created to protect public health. Reason for it is because certain percentage of medicine in circulation a part of medicines sold in pharmacies is counterfeit. It Law requires that all prescription medicine produced or imported in the EU have specific, unique code on the packaging for purpose of tracking and verification that medicine is genuine. Legal framework was in development since 2013, and as of since February 2019 law is in force in almost all countries in EU. Some countries got extension period for adoption. In the beginning , when law kicked in, there were many issues with interconnected systems. Real world usage Required usage of the FMD system simply didn't match to the processes and procedures that are already in place in many companies. Therefore, many countries decided to go with soft launch, which gave grace period for companies to adapt. That means that use of the systems was mandatory, but errors were ignored. , like before. That gave everyone time to polish out the issues.One more time, without edits.Falsified Medicines Directive (FMD) is law in the EU created to protect public health. Reason for it is because a part of medicines sold in pharmacies is counterfeit. Law requires that all prescription medicine produced or imported in the EU have unique code on the packaging for purpose of tracking and verification that medicine is genuine. Legal framework was in development since 2013, and since February 2019 law is in force in almost all countries in EU. Some countries got extension period for adoption. In the beginning there were many issues with interconnected systems.Required usage of the FMD system simply didn't match to the processes and procedures that are already in place in many companies. Therefore, many countries decided to go with soft launch, which gave companies grace period to adapt. That means that use of the systems was mandatory, but errors were ignored.This looks clearer to me. Paragraph could benefit from more details on FMD, what were the problems, what are the results after year an a half of usage. Overall, it's more readable, and more comprehensive to potential readers that need simplified English. That is not bad, even Wikipedia has simplified English as one of the options. It's great way to globally share information while levelling the playing field between native and non-native English speakers.What do you think? Write me back @tbejnConclusion
Did I already say that writing is hard? Well, it's easy if the goal is that nobody reads it. But if you want to actually send a message, provide valid information or simply entertain a reader, rewriting is great way to start.

Teaching myself to write - After chapter 2

Second part of the book though me about importance of unity, chaining sentences by providing leads and ends and do’s and don’ts that I’m yet to remember. It was easy to remember to always have defined scope that you are writing about. It is that I need to stick to one pronoun, if possible. It’s more difficult to stick to one tense, and consciously move the reader through time. And it’s really difficult when it comes to usage of verbs, adverbs and adjectives. This is an issue for me, non-native English speaker. English words don’t carry same weight to me and native English speakers. For me, they carry information. For native speaker, they add color and tone, and all other small non-quantifiable elements. I’m not sure that I will ever be able to sense the language at that level. Therefore, I’m going to stick with writing about the facts and information that can’t be ambiguous.This time I’m going to write three shorter paragraphs and try to apply advice given in parts one and two from the book. Theme of this exercise is about love/hate relationship with scrum. First draft
If you ever worked in a software development company, you probably heard of word scrum. Some love it, some hate it. Yet it somehow managed to become defacto standard and must have for most software companies, small and big. But why there are so many mixed feelings about it if it’s widely accepted as best practice?
Scrum as idea is is old, but scrum in practice is not really that long around. Approximately 10 years ago first version of guide was published by Scrum Alliance. It definitely gained popularity thanks to other agile development methods, and it’s one of the leading buzz words today. Issues with scrum come from its flexibility. Therefore issue can’t really be adhered to scrum, but to the implementation of scrum within a team. Often teams start with scrum method and without fully embracing it pick what they find appropriate in one moment in time. Of course, quite often one person vision of how scrum should work is other persons nightmare. Combined with many other factors like health of the business, age of the company, size of the company, and other processes within the company, people actually end up bashing on scrum not because of the scrum, but because of the way the company works. Processes are not well defined, people are ok with jumping over them and bending everything to meet goals, and when scrum process is added to that formula it’s just pure mess. No wonder it gets bad rep.
So what to do about it? It’s not issue with the scrum, per se. Issue is quite often that it’s not right fit for the company it current state. Company first has to figure out how they want to work, and build from there. Running in 2 week long sprints is not going to help anyone. Slow down.First read-through
All right, like previous post, I’m going to take 5 mins, read the text aloud and then jump to the corrections and rewriting. I started to get some unnerving feeling while writing, which I attribute to slowly building sense for what is good and what is not. I’ll be back!After reading
Text is awful. There is no explanation what scrum is for people outside of the IT world. Second paragraph is too long, and sentences are not logically leading from one to another. There is too much jumping in context of tense. There are too many words that are unnecessary, and yet too little is said. Let me try to rewrite it.Rewrite 1
If you ever worked in a software development company, you probably heard of word scrum. It is a software development methodology developed by a group called Scrum Alliance about 10 years ago. It gained popularity together with other agile development methods because it promises fast and iterative development. Despite the promises, scrum methodology has both advocates and haters. Despite that, it somehow managed to become widely accepted best practice for large number of software companies, no matter the company size. Question arises - why are there so many mixed feelings about it if it’s widely accepted as best practice?
Issues with scrum come from its flexibility. Therefore issue can’t really be adhered to scrum methodology, but to the implementation of scrum within a team and company. Often teams start with scrum method without proper adaptation of the rest of the company. For scrum to work, expectations of all other parts of the company that depend on software team(s) should be aligned. That means that work coming to the scrum team must be prepared in such way that team can commit to delivering it within fixed time. It also means that no shortcuts should be done that disturb the team during development. If processes are not well defined, if people are OK with jumping over rules and bending them to meet goals, trying to force scrum method is just adding to the mess. Developers get upset about processes and most commonly lack of them, and scrum is not helping them. No wonder scrum gets bad rep.
So what to do about it? It’s not issue with the scrum, per se. Issue is quite often that it’s not right fit for the company its current state. Company first has to figure out how they want to work, and build from there. Running in 2 or 3 week long sprints - which is common smallest time unit within scrum - is not going to help anyone. Slow down.Second read-through
It’s a bit better, but sentence chain is still weak. I’m again going to take 5 minutes and I’ll try to do one better.Rewrite 2
If you ever worked in a software development company, you probably heard of a word scrum. If you haven’t, all you need to know is that it’s a software development methodology developed about 10 years ago. It gained popularity together with other agile development methods because it promises fast and iterative software development, while protecting the development team from disturbances. Despite the promises, it doesn’t work out for every team, and there are developers that hate it. Yet, it somehow managed to become widely accepted best practice for large number of software companies, no matter the company size. Question arises - why are there so many mixed feelings about it if it’s widely accepted as best practice?
Issue with scrum comes from the flexibility. Therefore issue can’t really be adhered to scrum methodology, but to the implementation of scrum within a team and company. Often teams start with scrum method while rest of the company might not be ready for the change. At minimum, rest of the company needs to create and follow process that is compatible with scrum method. That means that work coming to the scrum team must be prepared in such way that team can commit and deliver within fixed time. It also means that no shortcuts should be done that disturb the team during development. If processes are not well defined, if people are OK with jumping over rules and bending them to meet goals, trying to force scrum method is just adding to the mess. Developers get upset about process and most commonly lack of it, and scrum is not helping them. No wonder scrum gets bad reputation.
So what to do about it? A lot depends on case by case basis. In principle, there is no point in starting with scrum if expectations are not clear to all stakeholders. It takes effort to change way of working, and effort is needed both in and out of the development team. In any case it pays out to go step by step. Running in 2 or 3 week long sprints - which is common smallest time unit within scrum - is not going to help anyone. Slow down.Wrap up
This looks to be acceptable. Third paragraph is not anymore just simple summary of second paragraph, but clear and individual unit. Additional information is added to clarify some points, and all seems more fluid to read now. As always, I would love to hear your opinions, both on the method of learning and results of the rewriting. Especially from native English speakers. You can write me @tbejn.

Teaching myself to write - After chapter 3

The book - On Writing Well - is just getting better and better. After the first two parts, I got a grasp on what writing really is about. Jump to part 1 and part 2 if you are here for the first time. Part 3 offers advice on common writing topics, and luckily a couple of them are of my interest: science, technology and business. Concepts are straight forward, and I'm finding them less frightening than concepts from previous parts of the book. It's something that I feel that I can follow in my writing. Here is my takeaway from this chapter:
- Always explain things, don't assume that people know everything.
- Write like you would talk, don't be a pretentious ass.
- Most of the technical topics can be explained using simple language.
- When applicable, use simple metaphors to ease into the subject.
- Give enough levy to the reader to explore some side topics at their own leisure.
- Don't insult the reader by over-explaining things.Of course, general rules of good writing always apply:
- Sentences have to logically continue one after another.
- Don't use more words than needed, and every word should carry its weight.
- Don't use synonyms and adjectives to amplify things.Like in parts 1 and 2 of this series, I'm going to write about a topic that occupies my mind in recent weeks. It's about agile software development. This short story builds on the story from After chapter 2.People are good. No one is going to work every day with a plan in the head to ruin everyone's day. Yet, shit happens. One day you are sitting behind your keyboard, and everything is fine. You are developing software, making progress, playing your part. Suddenly, your boss comes in and tells you to drop everything you worked on for days to jump into something new. You are mad. You are thinking "Why the Hell we have a process if it's not followed? How are we ever going to do anything around here?"
If you ever had a situation like this in your line of work - no matter what you do for a living - you can probably relate. I'm not on this boss's side, but I'm inviting you to look through his lenses. He might be a bad boss that doesn't care enough about his or her peers. He could also be pressured to make such a decision. My point is that I don't justify his actions. I'm bringing attention that the software development process in your company isn't perfect. The business team is playing a different game than the software development team. You are on the same green field, but part of the team is kicking a ball while another is swinging around with a bat. Your boss might be somewhere in the middle with a basket of cookies. A terrible game to be a part of.Rewrite
In this rewrite, I'm going to focus on the clarity of the sentences, and logical order of them. Also, I'm going to write in the first person. I don't know what is going on in the readers' heads. But I have been in this situation far too many times.
I did this rewrite a few days after the first draft. I see that I was very emotional in the first draft, and all over the place. I think I managed to make it terse in the rewrite.I think that people are generally good. At least I hope that no one is going to work with a plan to ruin everyone's day. Still, bad things happen. Too many times I have been minding my own business, developing software, and then the boss comes in telling me to drop everything and focus on something else. I hated it. I used to think about all the situations where we would discuss the desired development process, and how we need to follow it to create a quality product, only to throw it all away. It all felt like it makes no sense to even try to do things right.
If you ever had a situation like this in your line of work - no matter what you do for a living - you can probably relate. I'm not on this boss's side, but I'm inviting you to look through his lenses. I don't justify his actions. I'm bringing attention that the software development process isn't perfect. The business team is playing a different game than the software development team. We are on the same green field, but part of the team is kicking a ball while another is swinging around with a bat. This boss might be somewhere in the middle with a basket of cookies. A terrible game to be a part of.P.S. I will write about some solutions in the next blog post.

Teaching myself to write - Before

I'm wondering how many people is in this same spot right now. Wanting to build something, something of their own. Full of doubts, what-if's. Yet without enough drive to cross that bridge. Spot that I'm talking about can also be clasified as priviledged. In 2020, when most people worry about tomorrow, I don't have to. Job is good, all basic needs are covered, yet something is calling me to try and create something of my own. Something. I thought that I always had bunch of good business ideas, until I learned how to grind them. Then I realized that most of them are garbage. I read bunch of amazing books, enough to understand how to build and eventually grow the small business, but all of them start with problem. I didn't have a problem that required solving. Now that's one first world problem right there.In my endless research one too many times was stressed out to learn to write. I know I suck at writing. English is second foreign language I learned, with very little formal training. Still, some small improvements can be done reading through propper material. Next series of articles is all about my atempt to learn to write. I choose On Writing Well by William Zinsser as my first learning step. Book is split in 4 parts, and after each and every part I will write one article on this blog. It will be another kind of book review - imiddiate application of learned material to writing. I'm going to write about applied technology in serialization, track & trace, counterfreight and similar domains, since that is what I currently do. Goal is simple - learn to write. But second goal is to go out and write. Not just for myself, but also for others, to write something valuable and to get valuable feedback. This article is refence point, ground zero, illiterate me. Stay tuned for more!

About

I know what bane means in English. It might sound weird to stick with that nickname on English speaking blog. I still like it, underdog is kind of my thing. I'm from Serbia, and I live in Belgium. I'm software engineer by trade, and problem solver by experience. You can see more about my work on my LinkedIn page.

Contact

I'm easily reachable both on Twitter and LinkedIn.