As a technical coach, especially when I am embedded in a team, it is hard to overemphasize the importance of using the phrase "I don't know," plus "let me go find out." or "I'll ask someone who I think can help us."
Being able to say "I don't know" is an important skill for developers if they want to be on a high-performing team. Without it, the team risks creating an environment of fear and delayed learning. So when I say "I don't know ..." as a coach, I am modeling behavior that will help devs succeed. And adding the second phrase models taking initiative. While many, perhaps most, devs are good at finding answers to things they don't know, there can still be cultural and other reasons why a developer might not step out of their usual domain.
If you have coaching responsibilities, either formal or informal, and you don't say "I don't know..." maybe ask yourself if you are missing an opportunity to model important behavior.
My adventures in Agile Software Development and Coaching from Ann Arbor, MI.
Wednesday, October 19, 2016
Tuesday, October 11, 2016
Guest Post: Thoughts on Re-evaluating Spring as a Framework for Building Well Maintainable Applications
I'm hosting this post for Brandon Zeeb, another software craftsman at Pillar
Spring Boot is good for the general populous. Not sure I’d recommend it for any greenfield development.
Spring Boot wraps up a lot of auto configuration that most developers, in my experience, do not understand. Spring Boot enables 3-6 annotations, 2-3 of which you cannot enable outside of Spring Boot. Those 3-4 common annotations explode out into at least 10 more annotations. In total, all those annotations create a large number of beans very few developers know exist. Only if you had been using Spring since version 2.0 and had followed it's growth through MVC (and its ViewResolvers) into the RESTy side (with its MessageConverters) will you know what it's actually doing. In short, very few developers I've found can actually be effective within Spring. If they try to find the right place for a thing, they spend more time reading documentation to find the right extension point (what base class does my @Configuration need to extend so that I can put this bean in the ContentNegotiationManager!?!?) and if they work around the framework they pay later when Spring works against them
If you're writing small micro services and you finish them and forget them I don't see a problem.
Though these days there are many more frameworks which are slimmer and offer a more obvious and easily testable environment which makes, in my view, Spring less relevant. (edited)
In short, I'm looking at more ala cart solutions. An example might be using Guice (for IoC) with Vert.x 3. There is pretty minimal frameworking, whatever your app does, you see very clearly. The examples online don't show what I believe to be the best use of Vert.x (and Guice), they put all the codes in one file and say "hey look how easy this is!". The Java APIs of Vert.x are incredibly clean, all interfaces, easy as hell to mock, which ties in well to properly abstracting and dividing the application into components
The built-in Hazelcast solves a lot of problems in architecture N-tier apps have.
Brandon Zeeb:
Twitter: @phasebash
Github.com/phasebash
Thoughts on Re-evaluating Spring as a Framework for Building Well Maintainable Applications
Spring Boot is good for the general populous. Not sure I’d recommend it for any greenfield development.
Spring Boot wraps up a lot of auto configuration that most developers, in my experience, do not understand. Spring Boot enables 3-6 annotations, 2-3 of which you cannot enable outside of Spring Boot. Those 3-4 common annotations explode out into at least 10 more annotations. In total, all those annotations create a large number of beans very few developers know exist. Only if you had been using Spring since version 2.0 and had followed it's growth through MVC (and its ViewResolvers) into the RESTy side (with its MessageConverters) will you know what it's actually doing. In short, very few developers I've found can actually be effective within Spring. If they try to find the right place for a thing, they spend more time reading documentation to find the right extension point (what base class does my @Configuration need to extend so that I can put this bean in the ContentNegotiationManager!?!?) and if they work around the framework they pay later when Spring works against them
If you're writing small micro services and you finish them and forget them I don't see a problem.
Though these days there are many more frameworks which are slimmer and offer a more obvious and easily testable environment which makes, in my view, Spring less relevant. (edited)
In short, I'm looking at more ala cart solutions. An example might be using Guice (for IoC) with Vert.x 3. There is pretty minimal frameworking, whatever your app does, you see very clearly. The examples online don't show what I believe to be the best use of Vert.x (and Guice), they put all the codes in one file and say "hey look how easy this is!". The Java APIs of Vert.x are incredibly clean, all interfaces, easy as hell to mock, which ties in well to properly abstracting and dividing the application into components
The built-in Hazelcast solves a lot of problems in architecture N-tier apps have.
Brandon Zeeb:
Twitter: @phasebash
Github.com/phasebash
Subscribe to:
Posts (Atom)