December 2018

211 tweets

I think many developers shy away from rebasing because it regularly cannot be
done automatically and you need a bit of practice to get used to a rebase flow
and all it's interesting states (WTH is an empty commit?!). >
/status/1069176992564682752

Replying to @coderbyheart

@Maxwell_Dev But if you are uncertain at
first remember to save your branch before rebasing. If you push it to origin
before a rebase attempt and you botch that rebase, you can do a git reset --hard
origin/my-branch and everything is nice again ;-)

Replying to @coderbyheart

(p. 7) Correlation between code review process satisfaction and code quality
satisfaction: I would totally agree. Tested software does not automatically mean
that it is high quality (readable, maintainable). I can spot man problems in
implementation which have 100% test coverage.

Replying to @coderbyheart

(p. 11) 60% review tests: when I make a code review I rarely look at the tests,
because I can tell from the implementation how testable the code is. It provides
no value for me to look at the test also because I know the purpose of the
implementation.

Replying to @coderbyheart

(p. 13) Use CR for Knowledge Sharing: I don't think it is a good tool for that,
since it happens after the fact, the code has already been written and that
makes it harder to make bigger or fundamental changes (redo all work). Pair
Programming is best to share knowledge.

Replying to @coderbyheart

(p. 14) Benefit of Code Review: Adherence to Coding Standards/Conventions - I
try not to make that part of a CR, that should be catched by automated tools and
linters. I have these rules as pre-commit hooks in the projects and also as part
of the CI run.

Replying to @coderbyheart

(p. 18) Reports / Metrics: I would love to see Code Coverage from tests in Pull
Requests. Also interesting would be Copy&Paste detection - I have nothing
against duplicate & modify, but I discourage having exact copies of code.
This can be hard to spot in larger changes.

Replying to @storchp

@storchp
@Paratron
@SmartBear Well if you look at the chart, Jira
seems to be the state of the art tool, because most people use it.

I think it is a horrible tool for requirements planning because it focuses on
issues and tasks (I know because I have to use Jira every day). >

I got some tips @NordicTweets how to improve
my workplace ergonomics and I now moved the screens further away (+15cm) and
also move the table higher so it fully supports my arms.
Embedded Photo

Replying to @coderbyheart

@benjamin Right now this repo could also be
named: "Things Markus cares about so much that he writes them down so he can
link others to them because he is too lazy to explain them over and over again".

Replying to @SmartBear

@SmartBear Hm, I'm not on your side of the
table, so my questions would focus more on the social aspect of code reviews:

  • what is good/bad behaviour from a reviewer
  • what level of detail is preferred
  • which tool enables collaboration on code best
Replying to @coderbyheart

Issue trackers like @Jira and
@github encourage issue reporters to add as many
issues as they like. What if instead issue trackers would show on the "create
issue" screen a linearized view of all issues, and what people are working on
now?

Replying to @coderbyheart

You could not select the priority from a list (major, minor, ...) but would be
forced to rank your issue within all existing issues because there can only be
one issue with priority 1, or 2, or 99. It's like having a kanban lane per team
member.

I got bitten today by a nasty #JavaScript thing:

const handler = async () => { try { return request(); } catch (err) { // I
wanted to handle request errors here // but since request returns a promise //
they won't get caught } };

We drove through the snow to #Røros Julemarked, it was not as cold as usual,
this town is one of the coldest in Norway, today it was rather warm with -2°.

Hm ./ #adventofcode day 6 bugs me. My solution solves the example, but not the
puzzle input. I tried other solutions which were accepted and they produce a
result which also is not accepted, and different then mine.
Embedded Photo

Replying to @coderbyheart
Replying to @Sasha_Goebbels

@VolkerGoebbels You could put it the other
way around. If these things I list are not available I will need a higher salary
to work for that company.

I have worked for startups in the past with a salary I would never work for at
body-leasers like Accenture.

Replying to @coderbyheart

So, I've completed Part One of "Mine Cart Madness" - Day 13 - Advent of Code
2018, but part 2 is still calculating (at ~0.5ms per tick). I wonder if there is
also a different approach to the solution.

They say, when making a sculpture, you only need to cut that away from the block
that's not part of the sculpture.

When preparing a talk, you first build a solid block with a thousand great
ideas.

And then you need to cut away your own ideas down to a few. THAT really hurts.

Replying to @e_p82

@e_p82 @davidpich
It's good that I will give this talk multiple times, so I can change the
emphasis depending on the audience. I can put the focal point on code for the
JavaScript folks, infrastructure details for DevOps people, and
approach/workflow for the testers.

Replying to @Ravetracer

@Ravetracer Twitter bietet ein viel höheres
Maß an Interaktivität mit den Followers, und es entwickeln sich sehr schnell
Diskussion weil auch andere schnell darauf aufmerksam werden (weil man sieht
wenn ein Followee einem Account antwortet, dem man auch folgt).

Replying to @coderbyheart

@Ravetracer Blogs sind sehr viel statischer
geworden.

Threads in Twitter lassen sich auch viel bequemer erstellen, man fängt mit
kleinen Teilen an, für einen Blog erwartet man schon eher eine in sich
geschlossene Abhandlung.

Replying to @Ravetracer

@Ravetracer Twitter hat das im UI auf der
Website und in der App bereits. Beim erstellen kann man mit ➕ weitere Tweets zu
einem Thread hinzufügen und alle auf einmal absenden.

Praktisch sind Threads nur Antworten auf einen vorigen Tweet.