Dominik Berner

C++ Coder, Agilist, Rock Climber

Project maintained by bernedom

Get a 20/20 vision for your product

A good product vision is the cornerstone for being successful at delivering software products1. Having a product vision that is tangible and accepted by your developers is one of the most important things to have, if teams are supposed to work in an empowered and self-organized way. A vision is not just a good advertising tool, but it is the foundation to creating a purpose for everyone’s alignment towards what the product shall be. It is a pathological pattern, that companies that struggle with creating good product or company visions, find it very hard to create alignment and motivation in those employees who are building and delivering their products.

  1. Actually this is true for any product in development, not just software. ↩

Read More

A commit a day keeps the boredom away

Most hobby projects die at the idea stage - Mine do not. A while ago I decided to revive an old idea of mine to implement the International System of Units as a strongly typed C++ library. In order to try to bring this project forward I tried an experiment: I would make at least one commit each workday for a month. A month later I am somewhat proud to say, that I kept this promise to myself with only one “comittless” day. But how does my pet project look now?

Read More

Decide to decide better

How good are your decisions? - Every day we decide a lot of things small and big. At work or any professional setting we often have clear deciders. This can be a senior subject matter expert, the traditional “boss” or some collaborative process in an emporwered team - it does not really matter. Contrary to our private live in business we often have to make decisions more explicit and documented, for instance in the form of meeting minutes. Some people are good at deciding, others find it very hard.

Read More

What secret agents need to work successfully

The core capital of modern companies are their employees. This fundamental truth is even more important for companies operating in areas that require highly trained and motivated people with a high degree of initiative. It is not just software companies that fit perfectly into that scheme, but almost any engineering-driven company and many, many companies outside classical STEM fields. After all as Humphrey Watts said: “Every business is a software business”. In the article “The James Bond Package” I wrote how having someone with the skills and mentality of James Bond in your company helps a lot when solving complex problems is daily business. However getting James Bond to work for you and then be able to unlock his full potential needs a company culture that fits the modus operandi of a secret agent.

Read More

The "James Bond Package"

Due to his combination of skills, motivation and initiative James Bond is the perfect agile problem solver. Agile working requires empowerment of teams and individuals, self-organizing and a different mentality than classical command-and-control structures. This is not just the case for the leaders but also for the people actually solving the problems and delivering the products. To perform in such an environment it helps if each and everyone of us shares a bit of what I like to call the “James Bond Package”.

Read More

Chase the dopamine and get motivated

“It is really demotivating, nothing gets done here.” A complaint I heard a few times in various settings. Sometimes just as a exclamation to vent steam, sometimes with a sigh and an edge of desperation to it. Surprisingly most of the time I hear this, it is from people that I esteem as far from lazy and quite capable of actually doing and completing things. But lack of motivation can strike the best of us.

Read More

How to iterate fast when developing software and hardware together

Iterate fast and often to make better products. This rings true not just when creating software but also when developing close to or together with hardware. IoT and fully automated Industry 4.0 currently are one of the big topics in the industry. And because of this integrated development between hardware and software becomes more prominent again. But reality is often that software- and hardware-engineers fail to work effectively together and because of this struggle with creating awesome products.

Read More

Quick and easy unpacking in C++ with structured bindings

Unpacking a fixed size container in C++ can be tedious, and require you to fiddle around with std::get or std::tie. But not anymore, thanks to the new structured bindings introduced in C++17. Unpacking anything with a fixed size into named variables never has been easier.

Read More

Don't fear large scale agile frameworks

Agile is successful and we know it. For years we scrum masters, agile coaches and change champions advertised and trained developers in the agile principles and the many frameworks and ideas out there. We have seen them grow and become self-organized and empowered. It was tough work, changing minds and grass rooting ideas with the developers. And it was frustrating when we hit the hard wall of culture-shifting not just teams but whole organizations. Our teams worked well but somehow the movers and shakers of the companies needed a lot of attention to bring them along. Suddenly out ideas and principles we instilled so successfully into cross-functional teams of developers, testers and engineers were under harsh critique. Somehow there always seemed a someone up a higher level that did not agree with what we tried to achieve. Countless stories of trying to put scrum into action on a contract that is essentially waterfall are indicators to that.

Read More

Better estimates by using applied linguistics

Planning poker, magic estimation, T-shirt-size estimation and even the famed #NoEstiamtes are too inaccurate - But there is a way to estimate to up to 50% more accurately by using a simple formula based on empirical measures and applied linguistics. Notice how developers use the same qualifiers for estimating workload over and over again? “It is just a minor bugfix”, “This is a huge, complex task”, “There is absolutely no way I can put an estimate on this one”. Heard this sentences or variations of it in the past? Your best estimations are lying in front of you in plain sight.

Read More

Do not leave your innovation to the engineers

We need to be innovative! - I heard this statement or a variation of it a few times over my past in working as a software engineer. We engineers love this, as we get more time to tinker with anything we find interesting - Which is a lot. The result are often better tools or tool-chains to make our life as developers easier, but very rarely the output of such initiatives improves something tangible for the users of the product we are working on. Why? Because on these innovation days we are usually stuck together with other engineers which means that we mainly discuss engineering problems.

Read More

Stop calling it agile

We should stop calling it agile and start calling it modern company culture. In the past fifteen years the word ‘agile’ has become widely popular in software development and other technology affine areas of business, but still people find it hard to find a consensus on what ‘agile’ means for them or their company. There seems to be an agreement that agile development contains such processes as scrum, kanban, xp or on a bigger scale SAFe, Less or any of the other frameworks out there. But an often heard complaint by people involved in software development is, that they are never “100% agile”. Or that they do scrum but find it hard to get that elusive culture shift happening in their companies.

Read More

C++17 - What's in it?

C++17 - is officially out! So what can we as coders expect from it? With C++17 the standard-comitee brought further modernisation into the language. C++17 brings a set of new features which enhances convenience for the coder and makes writing portable code easier.

Read More

Planning ahead the agile way

Agile is shortsighted! In scrum you are only interested in what’s going on in the next sprint! Kanban focusses only on what’s next! Long term planning is not agile! Sounds familiar? The gap between short term (sprint-)planning and long term roadmaps is an often discussed focus point in the world of agile and an often cited reason why “our company cannot do agile”. And it is true. A lot of litarature advertises mainly the fast reaction time and short iteration cycles that agile methods give us, especially if applied to software development. But it is also true, that a lot of businesses are operating on longer cycles than single sprints. Yearly budget allocations, fixed cost projects and hard deadlines are real and existing challenges in the industry. Leaving aside if this is how it should be or not, those practices are still alive and kicking in a lot of industrial sectors such as the medical or machine industry.

Read More

Five and a half steps to efficient meetings

Meetings are boring, overcrowded, take up much of your valuable time and don’t produce the desired results. Or they can be interactive, efficient, goal-driven, interesting and sometimes even fun. So how to go about planning and running successful meetings? Five and a half Steps to successful meetings

Read More

The Seven Must Reads For The Aspiring Agilist

Over the course of the last few years I read a lot of books about agile principles and teamwork and there are some that stood out to me as particularly worth to read. Most of the books are rather about agile teamwork in general than any particular methodology such as scrum or kanban. These books are also starting point on the way to knowing and doing agile, so the list is obviously by no means complete.

Read More

Get Professional - A professional skillset for software developers

Everybody is a great coder! It’s now over fifteen years since I first got money for a program that I wrote, and since over ten years I consider myself a professional software engineer. When I started out programming I was convinced that raw coding ability and deep, innate technical knowledge of a few programming languages would be all it would take to make it in the industry. But over the years I learned that there is more to being a professional programmer than hacking together complex code. Having worked both in academics and industry, this often became most apparent to me when working with newbies fresh out of college. Often they are great programmers, but lack some of the surrounding skills to make them look professional to me. So what distinguishes the common coder and/or hobbyist from the pros? Before I forget: This article is written on a purely subjective basis of my personal experiences, feel free to tell me that I’m wrong

Read More