Unwritten Rule of Engineering #6: Develop a “let’s go see!” attitude.
It is seldom adequate to remain at one’s desk and speculate about causes and solutions, or to retreat to … specifications, and reports and hope to sort it all out. Before ever being able to solve a problem, you will need abundant insight, insight that can only be developed by observing first-hand what might be at once too subtle and complex only to imagine.
What happened to rule #5? Well, the numbers are from the original book and I’m only blogging the most software psychologist-relevant rules, so sometimes I’ll skip a rule or two and thus a number or two.
Unwritten Rule of Engineering #4: Confirm your instructions and the other person’s commitments in writing.
Do not assume that the job will be done or the bargain kept just because someone agreed to do it. Many people have poor memories, other are too busy, and almost everyone will take the matter a great deal more seriouesly
if it is in writing.
Unwritten Rule of Engineering #3: Do not wait passively for anyone — suppliers, sales people, colleagues, supervisors — to make good on their delivery promises; go after them and keep relentlessly after them.
Many [engineers] assume that it is sufficient to make a request or order, then sit back and wait until the goods or services are delivered. Most jobs progress in direct proportion to the amount of follow-up and expediting that is applied to them. Expediting means planning, investigating, promoting, and facilitating every step in the process. Cultivate the habit of looking immediately for some way around each obstacle encountered, some other resource or expedient to keep the job rolling without losing momentum.
When you take responsibility for delivering something, you take responsibility for the whole supply chain. Boeing famously discovered this truth with the 787 program. As Boeing engineer Hart-Smith said (years in advance of the problems):
If [taking ownership of whole supply chain] is not done, the performance of the prime manufacturer can never exceed the capabilities of the least proficient of the suppliers. These [risks] do not vanish merely because the work itself is out-of-sight.
Unwritten Rule of Engineering #2: Demonstrate the ability to get things done.
A combination of three basic characteristics:
- initiative, which is expressed in energy to start things and aggressiveness to keep them moving briskly,
- resourcefulness or ingenuity, i.e., the faculty for finding ways to accomplish the desired result, and
- persistence (tenacity), which is the disposition to persevere in spite of difficulties, discouragement, or indifference
Unwritten Rule of Engineering #1: However menial and trivial your early assignments appear, give them your best efforts.
Many young engineers feel that the minor chores of a technical project are beneath their dignity and unworthy of their college training. They expect to prove their true worth in some major, vital enterprise. Actually, the spirit and effectiveness with which you tackle your first humble tasks will very likely be carefully watched and may affect your entire career.
… [Long term] success depends so largely upon personality, native ability, and vigorous, intelligent prosecution of any job that it is no exaggeration to say that your ultimate chances are much better if you do a good job on some minor detail than if you do a mediocre job as a project leader. Furthermore, it is also true that if you do not first make a good showing on your present job you are not likely to be given the opportunity to try something else …
As a manager, and now an executive running a software organization, I definitely agree: we look to give greater responsibility and authority to people who are doing a great job regardless of the assignment over those who only excel on specific projects.
An interesting article about how best intentions go awry:
“A true leader is one who inspires loyalty with no regard to rank or position.” Also “companies must understand that a culture will form whether you like it or not. Shouldn’t you have some say in its direction?”
Five thoughts on the topic including: “3. Employees Mirror Leadership and Unwritten Rules“:
A use case demonstrating why it’s hard to test software. Of course hard doesn’t excuse the necessity of doing so, but it is hard:
I’ve experienced working in environments with each of these styles over the years and they aren’t happy places:
My talks that have ended with a call to action have always been more powerful:
There is so much opportunity out there for good people that the only attraction you have is the culture you’ve built, so why not make sure that is front and center?
These guys are doing cool stuff:
And of course no trip to a library is ever for nothing!
While re-reading The Unwritten Laws of Engineering , the 1944 classic that is a crucial compilation of “house rules,” or a professional code, I realized that most of them also apply to modern software engineering. So, for the next few months I will blogging out one rule every few days, perhaps with a little color commentary about the modern practices. (Or you could buy your own copy and read ahead.)
This is the model I’ve been using at New Relic:
And of course this is true:
10x engineers are smart, but there are a lot of smart people in the world, so what makes the difference between a smart person who is 1x and a smart person who is 10x?
An essay about what happens with values when you reach Dunbar’s Number:
An essay about why some constraints are important, even when they seem counter-indicated:
An interesting economic argument about taxis vs Uber:
I value Wikipedia but at the same time I value expertise, so I’ve never quite been comfortable with the Wikipedia model of anonymously crowdsourcing everything. I wish that Wikipedia had editor CVs. But be that as my opinion, here’s a nice history:
Smalltalk is one of my favorite programming environments of all time and I agree that it has a lot of lessons for those who care to pay attention:
Just writing more tests doesn’t make things better. Good tests need low mental overhead.
Most internet lists are useless, but here’s a good one about management: