J
Johannes Brodwall
johannesbrodwall.com · Personal blog · on HN since 2010
Johannes Brodwall is a Norwegian software developer writing about Java, test-driven development, architecture, and code quality.
What HN saysCommenters cite his posts on TDD with Sudoku, running Jetty in production, and database refactoring as practical examples backing their points.
15HN people shared it
5linked it in comments
19stories submitted
106story points
8 years agolast shared
2010people per year2026
Most-shared posts
- 1Forget about Clean Code, Let’s Embrace Compassionate Code4 people · 13 points · first shared 2018 · 2 comments on HN
- 2Why TDD makes a lot of sense for Sudoku2 people · 4 points · first shared 2010 · discussion on HN
- 3A wicked Java trick to make the JVM forget to check exceptions2 people · 2 points · first shared 2018 · discussion on HN
- 4Why I stopped using Spring1 people · 55 points · first shared 2013 · 46 comments on HN
- 5Dirty Code Monday1 people · 18 points · first shared 2018 · 3 comments on HN
- 6The madness of layered architecture1 people · 4 points · first shared 2014 · 1 comments on HN
- 7This dependency injection madness must end1 people · 3 points · first shared 2011 · discussion on HN
- 8Bare-knuckle SOA1 people · 2 points · first shared 2012 · discussion on HN
- 9Horizontal reuse in JavaScript and C#1 people · 1 points · first shared 2014 · discussion on HN
- 10How to write better code1 people · 1 points · first shared 2018 · discussion on HN
- 11Why and how to use Jetty in mission-critical production (2010)1 people · 1 points · first shared 2011 · discussion on HN
- 12Humble Architects (2013)1 people · 1 points · first shared 2015 · discussion on HN
- 13The Economics of Reuse1 people · 1 points · first shared 2014 · discussion on HN
- 14Crud rest rails1 people · first shared 2014
- 15Offensive programming1 people · first shared 2018
What HN people wrote when they linked it
dmmalam · 2015-09-01
Did you consider using views/triggers on the database to migrate to the new API? [1]. Would still have to change all models, though static typing would make this much easier/safer.
[1] http://johannesbrodwall.com/2010/10/13/database-refactoring-replace-ta…
nthj · 2014-03-21
I think it was this one, but unfortunately I can't find the whole video.
https://www.youtube.com/watch?v=mp4z2eK1Avw
http://johannesbrodwall.com/2007/02/27/crud-rest-rails/
swah · 2013-02-22
I enjoyed the ideas on http://johannesbrodwall.com/2010/03/08/why-and-how-to-use-jetty-in-mis… for similar reasons.
torial · 2010-08-20
I'd take the imperfect studies listed in the article I provided over two anecdotes. However, for the scenario of using TDD with the Sudoku, where it was done with less chaos, other anecdotes are there: http://johannesbrodwall.com/2010/04/06/why-tdd-makes-a-lot-of-sense-fo…
I say this as a person who likes Norvig more than I like TDD (I'm interested in TDD to see if it is useful for my day to day work, Norvig is more of my high level guilty pleasure, such as his spell checker article or his speech on using lots of data and then algorithm becomes less important)
kolinko · 2018-05-02
> - beware of premature optimization. Spend that time on defensive code, comments and tests. Optimize based on measurements, not feelings
In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.
Also, offensive programming is a thing, and possibly less bug-prone in some situations:
http://johannesbrodwall.com/2013/09/25/offensive-programming/
> - be nice and never argumentative
This too depends on context and a team. Personally, I prefer argumentative people (within reason) to nice ones - the last thing I want is for a developer to do something he believes is stupid, and not tell me about it.
Having said that, being too argumentative is not good either - some devs seem to build their self esteem based on the number of arguments they won. No no no.
> - take notes when getting tasks and make sure you don’t miss anything
This is super-true. Also - read a tutorial on active listening. I had a team of developers once who literally made zero notes from the meetings.
> - be humble when getting criticism and be merciful when giving one
Just not too merciful :) A good book on managing people, including giving feedback: https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01KTIEFEE
As for being humble when getting feedback - I'd add "don't afraid to ask as…