Tools of the craft
Who should be responsible for the development tools engineers use at work?
I never liked my employers imposing toolchains on me.
I was a coder since around twelve. In high school, I learned Linux. During college, I worked in IT as an AIX and Solaris admin, moved on to Windows C development and Java. At every job I have had since college, I came in with deep knowledge of the tools I use, strong opinions about which tools I want to use, and the ability to set up and maintain my own development environment.
I recall my first job out of college in 2000, where I worked on one of the first online banking apps in the US at a major bank. I spent the first few days setting up my development environment just like I liked it, including writing build and test scripts. I watched in astonishment how people with 10 years of experience on me and much higher pay waited for me to show them how I got set up.
Great surgeons design and create their own tools. Best car mechanics bring their own as well. Developers who take responsibility for their own tools are also considered more productive.
Over the years, I’ve worked with developers who, like me, would be much happier bringing their own computers and tools to work. I’ve also worked with developers who don’t even know how much RAM their computer has, or what RAM even is.
What works for some developers may not work for others. A lot depends on how they like to work and what work they do. There is little reason to impose a mainframe-style remote IDE upon a JavaScript front-end developer. Forcing a backend developer into a Chrome-based IDE will drive them nuts. An iOS or Android developer has no choice and must use the tools Apple and Google require them to use. Finally, a full-stack developer is likely to prefer a high-end commercial jack of all trades IDE.
I acknowledge that some standardization is needed on large projects with complex architectures. A large project uses a set of programming languages and frameworks and expects a certain degree of conformance from the engineers. However, developers must be active participants in their own productivity at the end of the day.
There are basic aspects of their own development environment a developer should be able to configure on their own. A developer should know how much memory and CPU their computer should have, what operating system they prefer, and the basics of networking setup, including knowing the right settings for their corporate environment.
Developers should feel empowered to configure their environment and development tools to their liking and contribute to the shared team standard. They should know the libraries they picked and why they picked them. They should be able to articulate why they like one programming language over another. As part of their job, each developer should be able to state clearly and in actionable terms how they’d like to work.
I never liked my employers imposing toolchains on me.
I was a coder since around twelve. In high school, I learned Linux. During college, I worked in IT as an AIX and Solaris admin, moved on to Windows C development and Java. At every job I have had since college, I came in with deep knowledge of the tools I use, strong opinions about which tools I want to use, and the ability to set up and maintain my own development environment.
I recall my first job out of college in 2000, where I worked on one of the first online banking apps in the US at a major bank. I spent the first few days setting up my development environment just like I liked it, including writing build and test scripts. I watched in astonishment how people with 10 years of experience on me and much higher pay waited for me to show them how I got set up.
Great surgeons design and create their own tools. Best car mechanics bring their own as well. Developers who take responsibility for their own tools are also considered more productive.
Over the years, I’ve worked with developers who, like me, would be much happier bringing their own computers and tools to work. I’ve also worked with developers who don’t even know how much RAM their computer has, or what RAM even is.
What works for some developers may not work for others. A lot depends on how they like to work and what work they do. There is little reason to impose a mainframe-style remote IDE upon a JavaScript front-end developer. Forcing a backend developer into a Chrome-based IDE will drive them nuts. An iOS or Android developer has no choice and must use the tools Apple and Google require them to use. Finally, a full-stack developer is likely to prefer a high-end commercial jack of all trades IDE.
I acknowledge that some standardization is needed on large projects with complex architectures. A large project uses a set of programming languages and frameworks and expects a certain degree of conformance from the engineers. However, developers must be active participants in their own productivity at the end of the day.
There are basic aspects of their own development environment a developer should be able to configure on their own. A developer should know how much memory and CPU their computer should have, what operating system they prefer, and the basics of networking setup, including knowing the right settings for their corporate environment.
Developers should feel empowered to configure their environment and development tools to their liking and contribute to the shared team standard. They should know the libraries they picked and why they picked them. They should be able to articulate why they like one programming language over another. As part of their job, each developer should be able to state clearly and in actionable terms how they’d like to work.