I haven’t tried it yet, but the idea of a performance and security boost and, oh yeah, the ability to write plugins in .NET is enticing for projects like this blog. I’ll add this to my list 🙂
The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.
And the best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum.
That’s one of the only ways you can achieve the temporary glory of a hybrid manager+tech lead. This is an unstable combination, because your engineering skills and context-sharpness are decaying the longer you do it.
I have been on my latest hybrid manager + tech lead gig for a few months shy of two years now – it’s not the first time for me by any stretch. It was incredibly validating to hear this swinging back and forth that I do as NORMAL.
I’ve added a link to my most recent project… which is still in progress – it is an IoT weather station I started developing as part of my MSEE at UW. So happy to be working with embedded devices again.
Check out the Projects link in the menu above to learn more. I’ll be adding more media and details to the repository Wikis soon.
Remote Development is my new favorite VS Code extension. Not only does it seamlessly present the remote file system, it presents the GitHub state like it would for local files and includes an easy to access terminal. Nicely done, Microsoft 🙂
In software development, a phrase that gets used frequently is “code smell” – referring to an “odor” that code has or develops due to poor initial design or inattention to refactoring during continued development or maintenance. Hallmarks of “code smell” include things like copying and pasting blocks of code instead of refactoring into callable functions, classes that have or develop multiple responsibilities, overly broad interfaces, and so on.
I think engineering departments can have smell too. Hallmarks of engineering smell include:
teams that develop processes, tools and frameworks with no expectation of coordinating efforts with other teams; effort is duplicated and uneven; autonomy and flexibility are valued much more highly than collaboration and long-term efficiency
teams are made responsible for maintaining more active products than they have resources for; the business comes to count on heroics and although many products are offered, quality and response times are poor and competitors have more up-to-date feature sets
teams launch “V1” of a product and then are re-assigned to focus on another product; engineers are given limited opportunity to develop architectural expertise before being reassigned elsewhere; sense of ownership suffers; architecture rots in place as only critical patching is permitted
teams avoid choosing service or product related names since there is the expectation of frequent product focus reassignment; or in the case of contracting, the business usually fails to win a contract renewal for subsequent work beyond initial efforts (or fails to direct the expertise developed in the contract into their own offerings)
career growth is narrowly defined to include skill acquisition only; there are no levels; hiring is limited to a narrow band of experience ranges; mentorship is not a priority since recruiting purposely attempts to hire engineers of similar ability
in addition to discouraging technical hierarchy, non-technical career growth is also narrowly defined to skill acquisition; leadership roles available to individual contributors are end with becoming a team lead and are not considered a promotion but a lateral
being a generalist is actively encouraged (makes it easier to assign you to something new for the next project) and developing deep architectural expertise is discouraged
This leads to key questions to ask when evaluating any engineering organization, whether you are a part of it, considering joining it, or contracting with it:
Against what standards can I expect the engineering organization to deliver? How can I judge the likelihood that the organization can deliver high quality, consistent work across all features and beyond V1?
What capacity is there in the organization to take on work? What evidence is there that underperforming products and technologies are regularly pruned to make room for new opportunities or to continue or increase investment in successful products? How much does this organization rely on heroics to make up for poor planning?
Who are the architects, the mentoring engineers? What are their visions for the organization and products and the technologies they work with? What evidence is there of allowing people to specialize, to learn and own something deeply long-term?
How are the teams named and organized? Are they aligned to products and services? Do they share processes and standards? Is a sense of product ownership actively encouraged? When a product is sunset, how are the engineers helped to find new homes in the organization? When a new project is undertaken, how is it staffed?
Are there career ladders — i.e. technical leadership and people management? Are there examples of people that have “risen the ranks” more than a single “rung.” To what extent is first line and middle leadership valued? Is it considered a promotion? Do they hire junior and staff engineers or is hiring limited to senior only? Are senior leadership positions routinely staffed from outside?
It’s the beginnings of a “sniff test” there. I expect I’ll be writing more on this. Comments?