DEV Community: Maximilian Koch

To reestimate, or to not reestimate, that is the question!

Maximilian Koch — Fri, 18 Oct 2019 15:39:44 +0000

In agile processes, like scrum, we tend to estimate our work. Not by time, but by complexity.

What does complexity mean to me?

Complexity is something, that consists out of a variety of factors:

The clarity on what needs to be done.
The agreement of the team on how to tackle the task.
The knowledge of the team that is required to get the task done.
Third party dependency, which can't be solved by the team itself.
Time also plays a roll, as a very simple task can also be rather time consuming.

I'm sure that there are also other aspects on complexity.

Sometimes, we estimate a bunch of stories, but not all of them will make it any of the next iterations.

Here are two cases I stumble occasionally over:

Case 1:

Imagine that a story has been estimated with the complexity of 8, but still sits in the backlog for some time. A few iterations later, this story will finally make it in the next iteration. Since then, the team has learned a more about the previously estimated story and it seems like it is more/less work than anticipated.

Has the complexity of this story changed? Should it be reestimated or just left at the previous estimated complexity of 8?

Case 2:

Imagine that you have a story that needs to be repeated on regular bases. Something like: Release the kraken!🦑 Before the releasing the kraken first, the story was estimated as a 3. After some time, the team has gotten more and more comfortable with releasing the kraken.

Has the complexity of releasing the kraken decreased? Should it be reestimated every time it needs to be done again or should it always stick to its initial complexity of 3?

IntelliJ google-java-format plugin vs IntelliJ java-google-style.xml - what's the deal?

Maximilian Koch — Wed, 16 Oct 2019 20:20:51 +0000

Code Style. One of those controversial topics, where everyone seems to have an opinion and no one seems to has the silver bullet.

Recently, I was caught up in a discussion on how to format chained methods or in that case Java stream().

Here are the two examples from this discussion:

Option A:

obj.stream()
    .map(...)
    .distinct(...)
    .collect(...);

Option B:

obj.stream().map(...).distinct(...).collect(...);

Personally, I feel like option A is nice to read, but not everyone feels the same way. This is perfectly fine, but it would be nice to have a set of rules and restrictions, which will settle this debate once and for all.

Luckily, we have decided to on a Style Guide, the Google Java Style Guide.
Having a style guide is a nice thing, but just referencing to the style guide if not really enforcing the rules. Furthermore, to make life easy, it is always nice to have some tolling, which will allow to combine the chosen style with IDE features, like auto-format.

For IntelliJ, I see here two options. It's either installing the google-java-format plugin or importing the java-google-style.xml.

One could think that both options are resulting in the same format, but unfortunately this doesn't seem to be the case.

As an example, the plugin would format streams like in the above shown option A, but the imported XML would go with option B.

Furthermore, if you're using Spring, the XML would result in this format for annotations:

@Autowired
private Entity entity;

Whilst the plugin would format it as following:

@Autowired private Entity entity;

These are just a couple of examples, but there are plenty of other differences. It surprises me as both, the XML and the plugin, are maintained by Google (or at least under their GitHub organisation).

So, this leaves a few open questions:

Is this supposed to be like that?
Could it be an issue with IntelliJ or the XML that the formatting is so different between the two options?
Which one is right or closer to the actual Google Style guide?
Is there a different tool, which is reliable for a reliable code formatting for Java?

Personally, I kind of feel that closer to the plugin. This is mostly because it seems to be much tighter and almost leaves no free for different styles. But is it too tight?

It's nice to be nice! - Code Reviews

Maximilian Koch — Tue, 15 Oct 2019 12:31:01 +0000

We all know it and hopefully we all do it: Code Reviews! But have you ever thought on how your comments may be perceived? Or have you ever been on been receiving end of a frustrating comment on your code?

Disclaimer:
When I talk about code reviews, I mostly aim for code reviews done on pull or merge requests in a written form. But most of this probably also applicable to actual face-2-face/pair code reviews.

Code reviews are something very intimate for developers, as we share our work with others, in order to get feedback. Sometimes, feedback can be harsh, and this is maybe why people are sometimes afraid of opening their code for to review.

But wait, shouldn't there be a common way of communicating feedback? Even on things that didn't go so well or could be improved? Maybe in a constructive manner? Oh yes, there is a way!

Here are a just few bad examples of rather less constructive comments on a pull request:

Why?
This doesn't any make sense.
I don't see the point of this.
This SHOULD NOT be implemented like this!!!
Why are you doing this?
I don't like this.

This are just a few examples to highlight bad and not constructive comments. Depending on how those lines are being read and perceived, they are also destructing the confidence and working morale of the review seeking developer.

Furthermore, any of those comments are the perfect start of a long, long, long text-based argument. And instead of having a few constructive comments and improvements, you'll end up with an 80 comments long code review where everyone is defending their own view.

Is that helpful? Probably not!

Okay... But what if something is wrong with the code or you really don't understand what is going on? How about not writing comments, just approve and refactor it silently later? Mhm... This doesn't seem right either, ha?

Here are few tips on how to improve comments on code reviews:

Be constructive:

Instead of just highlighting an issue, offer alternatives or ask for a quick white board or on-screen discussion.

Write sentences:

The comment "Why?" is not really question. How about something like this: "I'm having trouble understanding this, maybe I'm missing something. Do you have moment to explain this to me?"

Don't write in uppercase:

DON'T WRITE IN UPPERCASE, AS IT IS USUALLY BEING READ AS BEING A BIT AGGRESSIVE!!!

Don't dictate:

Instead of writing "You be should doing it this way: [...]", how about: "I've a few thoughts around this one. Could we meet for a quick chat about this?". Or maybe: "Nice! I recently found this on www.dev.to/some_article. Maybe you could give this one a try? Let me know how it went."

Keep it short and sweet:

Writing an assay about something in code review is usually not a good idea. This usually leads to very unproductive text-based discussions and sometimes loses track of the actual issue. Create a ticket for the topic to talk about or set up a meeting. This way it will be more open for a wider discussion with the whole team.

Imagine it would be you:

Do you like to read bad and not constructive comments on your code? No. I thought so much. Talk to people the way you would like to be talked to.

It's nice to be nice:

Saying phrases like: "Good work", "Good step in the right direction" or "This a good improvement", don't hurt to write. And even if the code in review has some flaws, someone spend time to write it and had the guts to open it up for people to review. This should be celebrated with appreciation!

This list could probably be extended and improved on, but I guess the message is clear. I believe, if everyone respects and follows basic communication guidelines, it will lead much less friction within discussions and will enable a team to focus on the cool things, like: Making Awesome Software together!

Here a couple of questions:

Do you know any no-go-phrases you have seen in code reviews?
How do you deal with bad language within code reviews?
How do you deal with a change you don't agree with as a reviewer?

And Keep in mind: It's nice to be nice!

Where to put the build and deploy scripts?

Maximilian Koch — Tue, 23 Jul 2019 14:30:49 +0000

Where do you store your build and deploy scripts?

I've seen multiple ways of dealing with this:

Keeping them within the Jenkins (or any other CI) Job.
Keeping them with the actual code all together.
Keeping them in a separate repository, as sort of a cookbook.

Whilst 1. is a complete no-go, as it is bypassing any kind of QC, 2. & 3. to my mind are valid options. I would probably lean more towards 2., as it is brings everything into one place. If everything is in one place, it is usually easier to maintain.

The only thing that could be against the 2. option is that if you change the build and deploy scripts, you technically need to bump up your projects version, which triggers a release/redeploy, etc.

I believe that is a small price to pay, compared to having n different repos, but option 3. could solve this.

What are your thoughts about this? Do you have a different strategy?

When a relative asks you, 'What you do for work?' What do you say?

Maximilian Koch — Mon, 17 Dec 2018 22:44:31 +0000

"Something with Computers", is that what you say?

I always try to explain what I do, but sometimes realise that I lost them not even half way through.

Since we get closer to Christmas, it is the time where we have these conversations with a lot of relatives who may have not seen you for a while.

How do you explain your job?

Or to make it simpler: Explain me your job, like I'm from a different generation. 😉

Bootcamp, how does it work?

Maximilian Koch — Sun, 28 Oct 2018 11:53:38 +0000

I myself don't have a CS degree, but did a German Apprenticeship which teaches software development skills over 3 years.

Recently, I see more and more people going for something called a bootcamp. From what I understand, you go to some remote place for 3 months and only learn about coding for the entire time. And at the end you get to meet company representatives to get contacts to find a job afterwards.

Sounds cool! I think, with the right attitude and the right employer this can work. You need to have an employer who allows you to make mistakes, you wouldn't do with some experience otherwise. But also to learn some other CS fundamentals around the job. I believe that it can work and that you don't really need to have the CS degree. I mean I don't have it. 😅

The three months things makes me a bit sceptical and the promise of a job as well.

How good do bootcamp graduates feel prepared for a job?
Do bootcamp graduates get a bit help from the employer to deepen their knowledge?
What are the expectations from the employer side to a bootcamps graduate?
What is the biggest pitfall or misbelieve?

I'd be nice to hear some stories from both sides. Bootcamp graduates and employers.

Ah, and before I forget:

Just in case, I'm also looking for someone who would like to talk a bit about this topic in a German speaking podcast. The podcast is called: @codestammtisch. Just give us a heads up on twitter. :)

Sub-tasking before estimation?

Maximilian Koch — Tue, 19 Jun 2018 17:28:01 +0000

Based on the book, we should first estimate and then we should sub-task our stories.

I personally have some issues with that. I find, sometimes, that doing an estimation on a task where we (as a team) are not 100% sure what it involves is difficult, and results frequently in underestimation.

I've the feeling, that sub-tasking first before the estimation could help with that. As it will show exactly what it takes to full fill the task and even team members who don't know that part of the codebase could better estimate it.

I've been told, that this could lead to blowing up stories, as it is not time boxed at the time of sub-tasking. But I think, if the product owner is clear with the acceptance criteria, this shouldn't be an issue and would rather produce a more honestest estimation.

What do you think?

How high is your projects code coverage?

Maximilian Koch — Thu, 07 Jun 2018 12:48:02 +0000

Is it always 100%? Do you not really care? Are you just testing the main functionality?

React PropTypes vs Typescript! Any experience?

Maximilian Koch — Tue, 08 May 2018 11:41:50 +0000

Why you shouldn't be stingy when naming variables!

Maximilian Koch — Thu, 12 Apr 2018 14:41:44 +0000

Recently I took over another project and as usual there is a bit of reading-into-it period to understand what is actually going on. It isn't a big project, but one of its classes had about 1.5K lines of code with X methods, which sometimes were very very long. In this moments I always ask myself: "Is it me or is it the layout of this class that makes it so difficult to understand?". I certainly sure about the fact that I'm not always the fast, who understands everything at once. But I think every developer has the obligation to try at least to make his or her code easily readable and understandable. Part of that is not writing looooooooong classes or even looooooooooooonger methods, but also how we name things.

I came across a lot of variables like: p, c, pc, pkAdd, etc., and I think that this is just not a good way of doing this. Sure, if you need a counter for a loop so, use c. I guess that is universal and everyone gets that. Based on that I recently posted a tweet (https://twitter.com/tschaka1904/status/984409479444824064), can you read it? :D

The point is, sometimes it is worth to write things out and use project, category, projectCategory and addProjectCategory. And surprise: Your IDE is doing almost all the magic for you 🧙‍♂️!

Keep your code r!

How do you deal with recruiters?

Maximilian Koch — Sun, 08 Apr 2018 21:36:12 +0000

Almost daily, I get LinkedIn notifications, of some recruiter who tells me "I have been reading your resume and I think you're a perfect fit" or "You're the one"-Messages. The thing is, and I believe that, that there are recruiters out there, who really care about good candidates. But most of the time, I get contact to subjects I don't really relate to. Something like, a C++ DEV position (I've never touched C++) or after moving company (and even moving countries ), they do contact me and try to convince me in their email that I would be a perfect fit. This is to some extend very upsetting, as they clearly just spam me... How do you deal with this kind of people? Just ignoring them?

How do you deal with a lot of meetings?

Maximilian Koch — Thu, 15 Mar 2018 07:05:32 +0000

You've a 3 weeks long Sprint and your manager wants you to go meetings worth 3-5 days of working time and this time isn't allocated in the sprint? How do you deal with this kind of situations? Do you take your laptop with you and keep working? Or do you work late after to get your work done? Or do simply tell your manager that this time hasn't been allocated in the sprint?