Recap of the Schneide Dev Brunch 2017-02-12

brunch64-borderedYesterday at sunday, we held another Schneide Dev Brunch, a regular brunch on the second sunday of every other (even) month, only that all attendees want to talk about software development and various other topics. This brunch was a little smaller in numbers of attendents, but very interesting nonetheless. As usual, the main theme was that if you bring a software-related topic along with your food, everyone has something to share. Because we were very invested in our topics, we established an agenda for the event. As usual, a lot of topics and chatter were exchanged. This recapitulation tries to highlight the main topics of the brunch, but cannot reiterate everything that was spoken. If you were there, you probably find this list inconclusive:

Household roboters

We started our brunch talk by mentioning the services our five years old roombas provide for us, especially keeping the floor free of any small things. The biggest effect when having an electronic pet like a roomba is that you learn to keep your things above ground, especially cords with expensive electronics on the other end. The continuous elimination of dust is just a positive bonus on top of your behaviour adjustment. You keep the floor tidy, the roomba just mercilessly enforces this rule.

Today, there are many alternatives to the original roomba and most have really nice features and abilities. So no matter what brand you buy, you’ll get a capable floor police.

Code Review priorities

In our recent dev brunches, we talked about code review tools and code review habits. This time, we talked about code review priorities and the sorry state we are still in with current tools. We worked out that its nearly useless to only show the diff with a few lines of surrounding code and expect a thorough review. Even the concept of “changed files” is rather distracting in an object-oriented language. But even the current tools are only as good as we make use of them.

The first priority of code reviews should be finding and eliminating bugs – “real” bugs that would have had surfaced in production otherwise and “hypothetical” bugs that could have shown up in production. This means that code review is in its core an activity for the user of the software. Only second priority is the understandibility of the source code. If the reviewer doesn’t understand the code, chances are high that nobody will, including the author in a few weeks or months. Cleaning up the code now mitigates the problem for the lowest possible cost because the “hurdle of understanding” isn’t raised yet. A code review should never work on the level of linters and should not address topics that can be checked by an automatic tool. Suggestions about refactorings should be kept to a minimum because they may serve no purpose if the code isn’t touched again. Refactor when the code is opened for the second edit, not on the first review. Review the code on the semantic level, not on the syntactic.

And keep in mind that code review tend to be used for conditioning remarks (“don’t do that”, “this is ugly”, “I don’t approve”, etc.). Try to avoid conditioning and strive to provide educational comments (“if you change this to that, then you’ll profit from this benefit”, “here’s a suggestion for a better approach and here’s why it is better”, etc.). But we also discussed that at this point, the code review remarks are probably better said in a pair programming session.

Code reviews are a powerful tool for development teams, but with power comes danger. Hopefully, we get adequate software tools to help us avoid the common traps soon.

Time management

Out of interest, we talked about some principles and practices to better manage one’s time.

The first thing to be aware of are the two fundamentally different schedules of management and development. The manager’s schedule is clocked in 30 minute intervals and driven by outside demand (meaning that a manager idles when not requested), while the maker’s schedule works with 4-hour blocks of uninterrupted, deeply concentrated work. You can probably see the problems that arise when somebody in a maker cycle is interrupted multiple times as if he was in a manager cycle. The first thing you can do is to announce your maker cycles (by clear “busy right now” indicators like headphones or a “do not disturb” sign) or announce your manager cycles much to the effect of consultation hours. Let your disturber know if he can disturb safely or if even the question causes damage.

Another important thing is to arrange your surrounding according to your schedule. Your schedule is so important that you should choose your service providers according to it. For example, if you work full time, look for hairdressers that work saturdays or dentists that offer appointments in the night. If you need to contact people for personal matters during work hours, allocate a specific timebox each day or at one day in the week and do it then. Announce this timebox to everybody who might want to contact you during work. This way, to can differentiate people that respect your (announced!) schedule and people that don’t. Depending on your rigorousness, you can cut the people that harm your schedule out of your life.

Work only with people who value your expectations (if reasonable). If you give a task to somebody, let’s say a craftsman, and state the deadline, you need to be sure the deadline is met without you checking or the craftsman will report back in time. Don’t give tasks to people who leave you in the lurch.

It all boils down to keep the control about your calendar. Whenever you give somebody else the opportunity to “conquer” a slice of your available time at their convenience, you increase your own inconvenience.

Karlsruhe C++ User Group

The year 2017 started with a new-founded C++ user group in karlsruhe that started with great events. David, the organisator of the user group is a regular attendee at our Dev Brunch and reported about his experiences with the boot process of the user group. He found a sponsor in the Clausmark GmbH and accompanied the monthly talks and programming events with a regular table that provides a similar format as our Dev Brunch, just in the night and not in the morning. We also talked about possible future content, and found code-centric “git guided live casts” a worthwhile format. Another format, the excellent code retreats are a great way to learn from others, but require a full day and not just two hours in the evening. The Game of Life kata is really fun, even when done repeatedly. Once you discover the solution in APL, you’ll want a special APL keyboard, too.

We are looking forward to hear great talks and meet cool people at the C++ user group Karlsruhe.

Sales knowledge

Our last topic in the bonus time (we were lenient with our scheduled time box, it’s sunday!) was about sales and the installation of sales knowledge and sales behaviour in a group of developers. We agreed that starting with Strategic Selling is a good choice because the process/framework is compatible with established developer culture and effective in its results. The resulting shift in the perception of occurrences is immediate and powerful. Strategic Selling is a rather old sales process that share some similarities with Solution Selling, another nerd-friendly process for complex business-to-business (B2B) sales.

Epilogue

As usual, the Dev Brunch contained a lot more chatter and talk than listed here. The number of attendees makes for an unique experience every time. We are looking forward to the next Dev Brunch at the Softwareschneiderei in April. We even have some topics already on the agenda (like a report about first-hand experiences with the programming language Rust and a discussion about the concept of provisioning). And as always, we are open for guests and future regulars. Just drop us a notice and we’ll invite you over next time.

Having a plan

As a software developer, I quickly learnt that having a plan is essential for the successful realization of a project. Of course, there are projects which seem to run by themselves – either because no problems occur or because their solution is trivial. However, the larger the project, the tighter the deadlines, the more you need a plan to retain control over it. And it is particularly easy to lose control over a project if you not only manage it, but also participate in its implementation.

A project leader is responsible for the outcome of a project. They have to keep track of its goals, must know its current state and how far it progressed. You can, for example, constantly prescind from present actions and problems and check them in order to find out if they bring you closer to your objective or if you are getting side-tracked. Useful techniques are time boxes as in the Pomodoro techniques: For a fixed time, you concentrate on a problem, and afterwards, you recapitulate your results and, if necessary, adjust your approach. Yet, this is probably not enough to reveal how far your project advanced – and for this purpose you can employ a plan.

Such a plan can show you the exact condition of a project: It will tell you which milestones are already reached, where you are at the moment and which tasks have to be tackled next – and most importantly, it will tell you if you are in time. Basically, a plan is a monitoring tool for a project. By molding the project according to the plan, it is possible to see wether everything is alright, to expose potential pitfalls and, in the worst case, to recognize early if the project fails.

Moreover, a plan can also improve the communication related to the project. On the one hand, you will be able to brief your clients on the course of the project. Even better, if you can publish your progress regularly in a form allowing your clients to verify what you did so far, you will create a feedback loop that helps you to meet the clients’ demands. On the other hand, a plan will give you a handle to communicate with the people involved in the project realization. The knowledge about the state of the project is spreaded, which will permit you to spend less time talking about the required actions and more talking about the actual solution.

How to plan

Now, I want to enumerate a few hints for constructing a plan. First, even though a plan is crucial for a project, it is not necessary to develop the perfect plan right from the start, and it is presumably disadvantageous to stick with it at all costs. Instead, it is completely fine to launch the project following a rough draft; you can adapt it to your needs anytime.

Next, you should think about the unit of time you use to organize a project. If its life span amounts to a few weeks, it might be appropriate to plan single days, but in case it covers several months or even years, you should not bother to deduce the duties for the last month before starting the project. However, you should keep in mind that you may adjust the granularity arbitrarily: You can, for example, plan the first few days of a project in detail, while you sketch later actions in terms of weeks and months. In this step, it is also important to identify possible deadlines which have to be met.

Furthermore, you have to divide the project into sub-goals that are easier to operationalize. Just like with time units, you do not need to split your project into equally sized tasks, but upcoming issues should be specified in higher detail. At this point, you must also estimate the resources required to solve the issues; this could be as simple as time or money, but also something more specific as hardware or software. If you have tight deadlines, it is vital to check if there are tasks blocking other tasks: They cannot be parallelized and hence, the required resource is not just time, but rather calendar time.

Finally, even if you are managing a project, you are probably not alone – and you should exploit that circumstance extensively. When you know that there is someone who is able to perform a task more efficiently, you should delegate it. This is not restricted to the actual work in the project, but also includes management tasks such as the estimation of efforts. By this means, you will distribute the knowledge about the project to your team and facilitate the take-over of responsibility if it becomes necessary. In fact, perhaps the best way to successfully lead a project is to render oneself superfluous.