Johannes Brodwall is a Norwegian software developer writing about Java, test-driven development, architecture, and code quality.
Commenters cite his posts on TDD with Sudoku, running Jetty in production, and database refactoring as practical examples backing their points.
> - 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…
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-for-sudoko/
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)
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-table-with-view/
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/
I enjoyed the ideas on http://johannesbrodwall.com/2010/03/08/why-and-how-to-use-jetty-in-mission-critical-production/ for similar reasons.