This week I continued to read about Individual Apprenticeship Patterns for CS448 – Capstone and focused on the “Stay in the Trenches” pattern. This pattern emphasizes the importance of gaining continuous hands-on, practical experience in the craftsman’s chosen field(s) at all levels, even as they may advance within a company. It can be common as software developers move up to transition to more managerial roles focusing on handling teams and deadlines rather than hands-on coding.

However, doing so will inevitably and quickly result in deterioration of the craftsman’s coding skills. Instead of getting too caught up in theoretical knowledge or managerial roles early (or at any point) in a developer’s career, developers should ‘stay in the trenches’ and continue working on practical/coding problems to keep developing and advancing skills and expertise. By immersing ourselves in the actual work, we’ll learn from the day to day experiences and continue to grow in ways that upper level managers often cannot. 

Often, I’ve heard of upper level software managers spending most of their time on coordination, time/schedule management and strategy/design planning – from a craftsman’s standpoint, only code project strategy and design planning are particularly applicable. While it surely is far more abstract and long-term or larger in scale, developers who are working hands-on with code are still managing and accomplishing tasks and exercising their code strategy and design skills. So when considering that hands-on coders will also further several other skills related to their craft, these managerial roles seem like a clear downgrade in terms of job quality and day to day activities even if it comes with a pay increase.

This brings up the final major point of this pattern, which really stuck out to me – identifying other avenues and ways for craftsmen to advance within their company/career and be rewarded for high-quality performance. Some practical examples could include a simple pay increase, more involvement in internal strategy meetings/decisions, job-title shift/improvement, etc. There’s no clear or definite answer here, but individuals in this position are probably in good standing as the company is looking to reward them, and they should communicate and work with company management to find incentives and reward mechanisms that align with the goals of both parties. If not however, this pattern stresses the importance of staying on the craftsman’s path and considering advancement positions at other companies that are more flexible.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Between sprint tasks, I continued reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye for Software Capstone course this week, focusing on the “Expose Your Ignorance” strategy. In professional environments, software developers are often expected to have a deep understanding of the various tools and technologies they work with, but it’s common to encounter unfamiliar domains/situations.

This strategy approaches these situations by being transparent with employers/teammates about their learning process rather than pretending to already know unfamiliar content – even if the individual is able to self-teach the content to be able to follow through. In reality, they will need to learn the new technologies/skills regardless, and transparency on this allows employers and peers to also see your learning skills and personal growth over the course of a project. 

In doing so, software developers are approaching their situation from an honest angle which is far better for building professional relationships and management expectation. In a manager role, I would much rather hear 

‘well, this API is new to me but I’m making headway in learning and implementing it. I hit an obstacle, which may delay me.’

Over an employee claiming they are an expert and then failing to deliver on time.

As a part of this, the text also differentiates between an “expert” and a “craftsman”.  While experts focus on mastering specific platforms or domains, craftsmen are driven to continually learn and adapt by broadening their knowledge base. Naturally, the craftsman can’t become a master in every topic, but master craftsmen have developed in-depth knowledge of a few separate areas of technology throughout their career and ‘apprenticeship’. So, while they may not be the absolute expert on any given topic, they will have the skills to learn, adapt and overcome challenges involving almost anything.

I appreciated this differentiation and definition of what it means to be a craftsman. Earlier this week, I had a conversation with Professor Meunier in CS497 where he described similar concepts as they relate to graduates and job applicants. As an interviewer, he/others understand that graduates will not have deep knowledge in several areas yet but looks for a wide breadth of concepts/tools we’re at least familiar with and at least one area in which we have a deep knowledge. This could be visualized as a “T” shape – wide topped with one deep portion, but master craftsmen develop a knowledge structure more like an “M”, with a wide breadth of topics and a few with deep knowledge.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.