Software Developer Assumptions

Typed languages are better when you are working on a team of people with various experience levels. The bigger your application, the more helpful is compiler support.

Stand-ups are actually useful for keeping an eye on the newbies. They help to detect a team member stuck in a loop.

Sprint retrospectives have their place so long as they are for actual improvements. They are the holy shit, well, that went poorly!, and not some awful scrum master driven waste of everyone’s time.

Developers should not be isolated or left to just code. Bypassing traditional product managers and agile product owners, they should talk directly to the customer. It always reveals more about the problem, in less time, and with higher accuracy.

Software architecture matters probably more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.

Java is quite a cool language. Modern Java with streams, modules, pattern matching, or structured concurrency is fun to use.

Clever code is not usually good code. Clarity trumps all other concerns.

Bad code can be written in any paradigm. Programmers steadily writing bad code should be fired.

So-called best practices are contextual and not broadly applicable. Call them good practices. Blindly following them makes you a fool. The agile community recognized the dangers. They only advocate good practices and emphasize the importance of the context in which they are applied.

Designing scalable systems when you do not need to make you a bad engineer.

Static analysis is actually useful. Scanners like SpotBugs or SonarLint regularly find errors and smells.

DRY is about avoiding a specific problem, not an end goal unto itself.

In general, RDBMS are better and simpler than NoSql solutions.

Functional programming is another tool, not a panacea. The real world has objects and often classes.

YAGNI, SOLID, DRY, KISS.

Pencil and paper are the best design and programming tools and vastly underused. Better are whiteboards to exchange ideas in a team.

Trading purity in exchange for practicality is usually a good call.

Adding more technology in response to a minor problem is rarely a good call.

Design is driven from requirements [4]. Building anything beyond those requirements puts you into the world of speculative, self-indulgent invention.

90%, maybe 95%, of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency [5].

After performing over 2000 interviews, I can say that standard human resources interviewing is thoroughly broken. Technical interviewing and peer interviewing work way better and are more accurate.

Agile approaches are more successful and more fun. Waterfall approaches suck ^[1].

DevOps advantages are worth the effort. Deliver frequently and automate. Each project should have a continuous integration, continuous delivery, and continuous deployment pipeline. The deployment can also be triggered manually. The deployment steps shall still be fully automated.

Static websites written in Asciidoc and using site generators such as Hugo are the solution how to document your architecture and technical product ^[2].

A software developer shall have formal training in computer science and software engineering. She should hold at least a bachelor’s degree. A software developer should understand theory such as e.g., CAP theorem and big O notation.

A junior Java developer shall pursue a formal Java programmer certification. The learning effect is not always huge, but as a team member, I have security that they know all basic concepts.
Modern Java supports such concepts as algebraic data types, functional programming, monads, structured concurrency. A professional developer shall apply them in her daily work.

People who stress over code style, linting rules, or another minutia are insane weirdos.

Code coverage has absolutely nothing to do with code quality.

Monoliths are pretty good in most circumstances. The key is to write modular monoliths. ^[3].

Micro-services require justification.