- It seems that all technical advice boils down to "Stop, Think, Execute, Verify." Skip any one item on the list and… twitter.com/i/web/status/9… 14 hours ago
- Hey, @shanselman I recently interviewed on @2ndCareerDevs and think it turned out really well. Would love to be a g… twitter.com/i/web/status/9… 15 hours ago
- Hey, @ShawnWildermuth I recently interviewed on @2ndCareerDevs and think it turned out really well. Would love to b… twitter.com/i/web/status/9… 15 hours ago
- Dealing w/Imposter Syndrome: Push through and do what the little voice in the back of your mind says you can't do.… twitter.com/i/web/status/9… 17 hours ago
- Hey, @kyleshevlin my friend @gblock said he has a good story for you. Should he just add himself to the list? github.com/kyleshevlin/se… 18 hours ago
My Ideal Development Shop
October 25, 2011Posted by on
Adron Hall posted “My Top 4 Ideal Dev Shop & Product Characteristics, Yours?” to his blog the other day and solicited responses from other developers he knows, including your truly. I wanted to take some time to think about it and put my thoughts in order before responding, so I started a draft blog post.
I have worked with Adron in the past and think we have similar thoughts on what makes an ideal development shop. But I did want to add a few thoughts on what he said.
For me, the ideal development shop starts with how that shop fits into the organization as a whole. Does the organization see the development shop as a set of interchangeable resources whose output needs to be closely managed and directed or as a tightly integrated group who contributes to the bottom line value and leadership of the entire organization? Are the developers locked down and told what tooling and techniques to use to deliver software or is the team empowered to make their own technical decisions and held accountable to delivery? Does that culture rise above the immediate two layers of management?
The other side of that coin is how the developers themselves fit into the organization. Do they come in and do their time, punching out at 5:00PM or are they actively engaged in the business attempting to add value every day. Do they think in terms of the business domain or attempt to hide in technical jargon? Do they attempt to deliver functionality to the customer as they requested it, asking for feedback to perfect it or push back adding constraints on what can be done based on vendor tooling? Does the team share a sense of common code ownership with no fear of modifying any portion of the code base or do they silo in areas of expertise refusing to let anyone in to their little playground? Does the team feel a sense of responsibility for the quality of their output or do they delegate responsibility to a faceless QA department?
I also want to know how the development shop relates to itself. Do the team members respect each other’s contributions and skills or are they constantly talking other people down? Do team members educate each other bringing the competency level of the whole team up or do they horde knowledge forcing peers to learn things the hard way? Do team members feel comfortable asking for help when they need it without fear of judgement? Does the team actively seek out and destroy friction, constantly looking for a better way to accomplish things or do they allow every possible road block to halt progress?
Finally, I want to know the quality of developers that make up the team. Do the developers actively try to improve themselves, both on their own time and the companies? Do the developers work on projects outside of work to help sharpen their skills? Do they enjoy learning and teaching others in a collaborative way? Are they active in the community both attending user group meetings and presenting? Do they feel a professional responsibility to produce good code, going out of their way to prove a feature works as requested?
I think all of these attributes add up and contribute to the type of team I like to be apart of and work with on a daily basis. Technical things like what tooling, frameworks and techniques to use all fall out of these attributes and at the end of the day don’t really help you ship software if the team is simply a cog in the waterfall with no sense of ownership or responsibility.