- 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
When Changing Your Environment Might Mean a Change in You
January 8, 2011Posted by on
On the ALT.NET mailing list, Wayne posted a very frustrated message about his experience working on teams that do not see eye to eye with him on how software should be built. Like me, Wayne has discovered a whole new world of technology and practices that excite him and feed his passion for being a developer. Also, like me Wayne has become disillusioned with his current and past work environments that will not allow him to completely rewrite their codebase to use an ORM and coworkers who don’t “get it”. He asked for advice and I recommend you read his message and the great set of advice he has received so far from folks like Greg Young, Sebastien Lambla, JDN and many others.
Below is my response to Wayne’s question, I thought it might be worth sharing with a wider audience. While it is written as advice for Wayne and presented here as advice for the world, it is more an expression of where my mind is at on the topic in my software journey. Simply, this is the way that I look at it now.
There is already a lot of good advice here in this thread, so instead of rehashing it I want to take a different bent and distill your own descriptions back to you.
Here is how you describe yourself:
- I still consider myself a relative junior developer
- I get disillusioned
- I leave
- whenever I encounter these scenarios it’s always as the "new guy" on the team
Here are the positive descriptions of your coworkers:
- This is a medium-sized company that (…) has been in business for several years
- software is the core business
- These are all established companies
- with experienced developers (…) that have many solid years of software under their belt
Ask yourself these questions:
- Why has the company been successful?
- What experience do these developers have that keeps them employed?
- Is there nothing you can learn from your current environment of experienced developers working on a shipping successful product?
- What business value does introducing an ORM or IoC Container add to the company?
Remember the Agile Manifesto? What things does it value most?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I think the biggest lesson I have learned in the last few years of being involved with ALT.NET, Agile and the Software Craftsmanship movement is to work effectively in a team environment and to focus on solving the problems of the business. I keep having to relearn this lesson over and over because like you I want to use new techniques and tools and get frustrated with coworkers who are not in the same technical frame of mind I am that day.
My advice to you is to be the best developer you can in the environment you are in. Try to learn from the people you work with. Just because they work differently than you does not make them a lesser person. Focus on adding value to the business and solving their problems. If you see a serious problem that you think can be addressed by a new technique or tool, spike on it and present it to your team in the context of solving that problem. Introduce tools at the edges of the core application and demonstrate how they allow you to work faster, more accurately and deliver what the business needs.
Finally, I will agree with other advice given here. Get involved with your local developer community to get some exposure to what kind of work environments are in your area and them some exposure to you. Get involved with an open source project so you gain experience doing development the way you want to do it. Start a breakable toy project of your own to scratch that new tech itch that nags at the back of your brain. And start blogging about your journey so we can all learn from your experiences.
One last parting shot, I recommend you pick up a copy of Apprenticeship Patterns. I wish it was around when I was starting out as a developer.