Weird and Wacky Engineering
Comment
Frank Eory
Agreed. "A" players aren't necessarily prima donnas, and as you said, they spend ...
Paul A. Clayton
What makes a good engineering culture?
Sylvie Barak
5/23/2012 8:19 PM EDT
An interesting post cropped up on Quora this week, entitled “What makes a good engineering culture?”
Edmond Lau, a software engineer at the question and answer network, said the thought had occurred to him after hearing hundreds of young engineers during job interviews describe what they liked or disliked about the culture of their previous company.
On the basis of those answers, and his own career experiences at Google, Ooyala, and Quora, Lau managed to distill the essence of good engineering culture into a list of Ten Commandments.
The first, he said, was optimization for iteration speed, meaning managers give engineers and designers the flexibility and autonomy to make day-to-day decisions without having to ask for permission. A streamlined process increased work motivation and productivity, said Lau, while cumbersome bureaucracy was kryptonite to ambitious engineers.
At Google, Lau recalled, any user-visible change to search results had had to be personally approved by Google VP Marissa Mayer, a decision Lau deems to have “significantly hampered innovation.”
The second pillar of a strong engineering culture, Lau posited, is a relentless push towards automation as a way to reduce operational burdens on engineers. “Automating solutions and scripting repetitive tasks are important because they free up the engineering team to work on the actual product,” he writes, adding that by ensuring that services are restart automatically after a failure is “the only sane way” to manage complexity at scale.
Third on Lau’s laundry list is building the right software abstractions, keeping them simple and reducing the need for custom fixes. “The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems,” said Lau, arguing that it was much better than fragmenting efforts over many ad-hoc solutions.
Developing a focus on high code quality with code reviews is also essential, according to Lau, noting that “cleaner code is easier to reason about, quicker to develop on, more amenable to changes and less susceptible to bugs.”
Lau recommends establishing a process for timely code reviews. Knowing that code will be reviewed by others tends to create (positive) peer pressure that should prevent “hacky, unmaintainable, or untested code” from making its way into the workflow.
“Counter-arguments that nimble teams don't have time to spend on code reviews ignore the technical debt that can easily accumulate from poorly written code,” he wrote.
Similarly, Lau argues for shared ownership of code, saying it reduces stress and responsibility for individual engineers while reducing the temptation to feel indispensable to a project.
Edmond Lau, a software engineer at the question and answer network, said the thought had occurred to him after hearing hundreds of young engineers during job interviews describe what they liked or disliked about the culture of their previous company.
On the basis of those answers, and his own career experiences at Google, Ooyala, and Quora, Lau managed to distill the essence of good engineering culture into a list of Ten Commandments.
The first, he said, was optimization for iteration speed, meaning managers give engineers and designers the flexibility and autonomy to make day-to-day decisions without having to ask for permission. A streamlined process increased work motivation and productivity, said Lau, while cumbersome bureaucracy was kryptonite to ambitious engineers.
At Google, Lau recalled, any user-visible change to search results had had to be personally approved by Google VP Marissa Mayer, a decision Lau deems to have “significantly hampered innovation.”
The second pillar of a strong engineering culture, Lau posited, is a relentless push towards automation as a way to reduce operational burdens on engineers. “Automating solutions and scripting repetitive tasks are important because they free up the engineering team to work on the actual product,” he writes, adding that by ensuring that services are restart automatically after a failure is “the only sane way” to manage complexity at scale.
Third on Lau’s laundry list is building the right software abstractions, keeping them simple and reducing the need for custom fixes. “The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems,” said Lau, arguing that it was much better than fragmenting efforts over many ad-hoc solutions.Developing a focus on high code quality with code reviews is also essential, according to Lau, noting that “cleaner code is easier to reason about, quicker to develop on, more amenable to changes and less susceptible to bugs.”
Lau recommends establishing a process for timely code reviews. Knowing that code will be reviewed by others tends to create (positive) peer pressure that should prevent “hacky, unmaintainable, or untested code” from making its way into the workflow.
“Counter-arguments that nimble teams don't have time to spend on code reviews ignore the technical debt that can easily accumulate from poorly written code,” he wrote.
Similarly, Lau argues for shared ownership of code, saying it reduces stress and responsibility for individual engineers while reducing the temptation to feel indispensable to a project.
|
|
|
|
|
Navigate to related information
daleste
5/23/2012 9:37 PM EDT
This is a good list. It is heavy on the software side, so some hardware guys should chime in. I still think the best thing you can do for productivity of engineers is to give them a good boss. It is hard to keep working for a good boss for very long these days with all of the changes going around. It is easier in a small company.
Sign in to Reply
prabhakar_deosthali
5/24/2012 7:12 AM EDT
One important point that can be added to the list is - Keep the review meetings to minimum . Meetings should be called only when somebody sees that he is slipping on schedule because of a problem.
Too many daily meetings eat up a lot up creative time of engineers and they are left with spending sleepless nights to worry about completing their actual engineering tasks
Sign in to Reply
GoGoGeek
5/24/2012 9:16 PM EDT
After 25 years I see the same pattern: arrogance bad! Good culture: show respect, be objective, be team oriented, open minded and be accountable.
In the past the engineer was proud to work for a company, She/he could identify with the company. That is pretty much gone in the US - wonder why. I still see this pride in Asia.
Sign in to Reply
C VanDorne
5/25/2012 8:51 AM EDT
Why? Perhaps it has to do with two things: 1)America's inherent respect for the individual, and 2) the, "anti-BIG" movement, as I call it, that is going on now. Big Business, Big Government and other "Big" institutions are in doubt. What's left but the identity of the sovereign individual?
That's the long view. On a more specific note the company-employee relationship has changed here in America. For many reasons, but chief amoung them is that managers and Government Compliance Offices (known to most as HR departments) have made sure that working for the likes of IBM is as vanilla and predictable an experience as working for the comapny down the road.
Sign in to Reply
Bert22306
5/25/2012 4:57 PM EDT
I agree with the trend, in the US, to more of a "free agent" self-identification, among engineers. Even those who work for large companies. And I don't think there's anything wrong with that trend, especially in view of how fast companies sell off divisions, or how readily they lay off employees these days.
I've been lucky to work for a (large) company that treats engineers right, identifies itself as an engineering company first and foremost, and my own managers have tended to let us do our thing. Not much micromanagement going on, at least, not unless the engineers prove that they can't carry on on their own!
Sign in to Reply
EREBUS
5/25/2012 5:07 PM EDT
In my experience, I could get better work done with a group of "B" players who followed a good process than I ever got from an "A" player. "A" players do what they want based upon their EGO that they can't fail. Unfortunately, they do. "B" players know they have limitations and are more likely to collaborate and help one another because they know that they ALL have to succeed or the project fails. Plus "A" players tend to be a pain in the A&% and difficult to manage. Who needs them!
Sign in to Reply
cdhmanning
5/26/2012 8:33 PM EDT
There is no problem with many A players so long as they know the role they are playing.
For a good understanding of dynamics, I highly recommend reading up on the Belbin team roles.
Where A-loaded teams go wrong is when too many of them are the Plant or Shaper type and far too much time gets spent on exploring perfect solutions rather than just making a good system.
The time when you *do* need A players is when the project needs a huge leap forward to get to a new level. Your B players just can't do that.
Sign in to Reply
EREBUS
5/27/2012 4:55 PM EDT
Perhaps, but the B players will always make you money with good solid products. A players are hit and miss. When they are good, they are very good. When the fail, they fail bigtime.
No matter how you look at it, A players are gambles,they are not team players, they do not communicate well, and forget about getting any useful documentation. You still need a core of B players to go in and restore order to the chaos left by the A player.
Sign in to Reply
cdhmanning
5/28/2012 3:29 PM EDT
I think reading about Belbin team structures would really help.
Perhaps by "A players" you mean Plant and Shaper types. Those that bring in massively new ideas and like to drive architectures and change. Clearly too many of those just makes for a mess.
Perhaps by B-players you mean the Completer-Finishers and others: the "worker bees" that need direction but work diligently until the product works properly.
Sure, if you are working on fairly pedestrian products that don't need a lot of technical innovation, then you want lots of Completer-Finisher types. You don't want a bunch of people making changes for the sake of change that they leave unfinished.
But a team full of Completer-Finishers won't get the job done if the product is completely new or a project needs some radical changes to get things going.
Like most things in life, you need a balance. There is no magic recipe (eg. three Comp[eter-Finisher to one Plant) as each project is different and each phase of development is different too.
Sign in to Reply
Bert22306
5/28/2012 6:06 PM EDT
I don't think these oversimplified generalizations reflect reality, however.
Reality is that the so-called A players spend a lot of time also functioning as worker bees (presumably what you call B players). But they still drive the innovation. The more of these you have, and I mean real ones and not just prima donnas who are mostly impressed by themselves, the better off you are.
Sign in to Reply
Frank Eory
5/29/2012 3:59 PM EDT
Agreed. "A" players aren't necessarily prima donnas, and as you said, they spend most of their time as worker bees functioning as members of a team, getting a project completed and out the door.
Yes, when a project requires a big leap forward or something radically new and different, you need your A players to achieve that. But those leaps aren't needed every workday, or throughout the duration of the project. The A players are critical at the architecture and concept phase, but they will not be content -- nor can the company afford -- for them to sit on the sidelines while the B players do the implementation, verification and release to production.
Sign in to Reply
Paul A. Clayton
5/29/2012 1:43 PM EDT
As cdhmanning pointed out, knowing the workers and developing and maintaining the "organism" is important (and not only for managers--knowing how to communicate with individual co-workers and with whom to communicate is important, not just facts but also emotional content).
One item that I recall from Brooks' The Mythical Man-Month (which has a lot of classic wisdom on project management) was the use of dual-track promotion, but perhaps this should be generalized to providing different reward structures for different people.
(Brooks' MMM also mentioned the distinction between status communication and actionable communication, which relates to the first rule. Status communication is not meant to be an invitation to propose solutions.)
Automation is only a one type of offloading work. Even some tasks which cannot be automated can be offloaded onto another person, allowing concentration on the actual work and not the necessary support activities. Not only does such reduce distraction, but it can also improve morale (when the offloaded tasks are not suited to the person) and provide apprenticeship opportunities (which is important for growing talent).
[to be continued]
Sign in to Reply
Paul A. Clayton
5/29/2012 1:43 PM EDT
[continuing]
One item only presented tangentially in the ten rules is the significance of interruption. While interruption often inhibits productivity (even strong multitaskers can suffer from unpredictable or frequent interruptions), it can also be important in supporting creativity. Part of the utility of 20% time comes from this. Some workers may need to be encouraged to step away from a problem (sleep has some of this effect), potentially by a co-worker rather than the manager.
Code review not only leads to more maintainable code but also helps expose assumptions which may affect component integration. (The reduction in the criticality of the single developer not only potentially reduces stress and hubris but also builds up the skills and familiarity of co-workers with respect to the component and with respect to the developer. Knowing a co-worker's strengths and peculiarities can improve morale and reduce communication overhead--well-founded trust reduces communication, knowing how to make a request reduces risk of miscommunication [less need for "ECC overhead" and retransmission].)
As Brooks points out (in MMM), communication overhead is a major constraint in large projects (where the significance of size is related to timing constraints). Some communication overhead is unavoidable--even a single developer can benefit from his/her own documentation--, but reducing this overhead is one of the reasons that more skilled developers add disproportionate value. However, high performance nodes will not be as effective if their network links are bad (poor communication skills, inadequate protocols), the routers are bad (when information is not sent to the proper destination or the proper "protocol" translation is not performed [e.g., filtering and organizing information to suit the target]), or the network topology is bad.
Obviously, I am not good at communicating given how long this reply is (while so much information is not expressed)!
Sign in to Reply