Faster WordPress via .NET with PeachPie

I heard about the PeachPie project recently on the Channel 9 podcast (one of my favorite podcasts) – it allows you to compile PHP and WordPress (and plugins) into .NET. As expected, there is a performance boost and also as expected, you don’t have to worry about arbitrary PHP running on your site – AND you end up being able to select and build the exact versions of WordPress and the plugins you’d like kinda like package.json does for modern Javascript apps.

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 🙂

Photo by J David Eisenberg from FreeImages

The Engineer/Manager Pendulum

I am so happy I tapped on Episode 27 of the POPCAST this morning. And so glad Dan interviewed Charity and especially the focus of the podcast: her post about the “Engineer/Manager Pendulum

I quote:

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

And the best technical leaders in the world are often the ones who do both. Back and forth.  Like a pendulum.

and

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.

The article concludes correctly:

It isn’t a promotion, so you don’t have any status to give up. Do it as long as it makes you happy, and the people around you happy. Then stop. Go back to building things. Wait til you get that itch again. Then do it all over again. ❤

Photo credit

Engineering “Smell”

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?

Photo by Csaba Tomcsak from FreeImages