Some recent hard learnings for me around hiring & recruiting…
When recruiting, minimize false negatives. i.e. rejecting someone you should have sent forward
But when hiring, minimize false positives. i.e. hiring someone you shouldn’t have offered to
Trust when recruiting. Verify when hiring. Mistakes happen when you do the opposite.
(Recruiting = attracting talent, hiring = sending an offer)
We often forget how incredibly new software engineering is, and that we would benefit greatly from learning from other fields.
I recently met an aspiring junior dev who had been in the US Army for 10 years. You better believe they’ll be bringing very smart, transferable ideas to our industry. We’re lucky they’re interested in software engineering.
This is one of the reasons why I’m excited about coding bootcamps and career-switching junior devs.
Lawyers have more than 2,000 years on us. Soldiers, architects, doctors, accountants and teachers even more so. It would be wise to consider that we barely know what we’re doing. Maybe we should take a page out of other professionals’ books.
Can we learn from other professions how to:
| Trade/Profession | How old |
|---|---|
| Soldiers | Prehistoric |
| Architects | Prehistoric |
| Doctors | Prehistoric |
| Accountants | Prehistoric |
| Teachers | Prehistoric |
| Lawyers | 2,200 years |
| Print Publishers | 800 years |
| Electrical Engineers | 200 years |
| Automotive Engineers | 160 years |
| Aerospace Engineers | 120 years |
| Software Engineers | 70 years |
| Developer Relations | 40 years |
| Data Scientists | 20 years |
| Coding Bootcamp Instructors | 10 years |
There was once a wise farmer. One day, her prize horse ran away.
“That’s terrible,” the neighours said. “We’ll see,” the farmer said.
The next day, her prize horse returned with a mate.
“That’s amazing,” the neighours said. “We’ll see,” the farmer said.
The next day, the new horse kicked the farmer’s husband and broke his leg.
“That’s terrible,” the neighours said. “We’ll see,” the farmer said.
The next day, the army announced a draft. The farmer’s husband, being injured, was spared.
“You’re so lucky!” said the neighbours. “How can anyone be so lucky?”
“We’ll see,” replied the farmer, and continued tending her crops.
Complaining about code quality is easy. Writing code that turns a profit is infinitely harder.
Your instincts might tell you to clean up technical debt. Or you might want to write a feature, or fix a bug.
But should you do it? Is it worth the expense in terms of dollars? Aesthetics, code quality, feature richness, even reliability are unimportant compared to the bottom line.
Which is exactly why code that makes money stinks. Most of the time, it ain’t worth fixing.
Instead, choose simpler technology that’s easier to manage. Talk to your users. Get involved on the business side. Write less code. You’re not just a coder, you’re a problem solver. So solve problems with your whole skillset. Not just with your programming skills.
You’ll have more fun, write better code, build better products, and make more money.
Programmers don’t just write code. We influence human behaviour and the policies and operations of human organizations.
Each tiny decision made by a programmer — the design of each API interface, class, function, and statement — has holistic effects on the software’s clients, and their clients’ clients. The engineers who built Stripe, Twilio and Algolia influence and decide the business processes of millions of client businesses. Those client businesses, in turn, have their own customers who are impacted by engineering choices made upstream.
Think about the impact of software engineers who create computer operating systems and programming languages. The engineers working on these pieces of software make choices that ripple through the economy. In turn, those ripples move through history.
You wield a lot of power. Use it responsibly.
When you walk into a car dealership, everything is spotless clean and polished-down, almost sterile. And that’s how it should be, because the job of the dealership is to help create an environment in which you and your family feel comfortable purchasing a car. Being a clean, welcoming, and neutral place is part of the function of the dealership.
When you walk into a mechanic shop, it’s very clear that you’ve entered a workroom. There are loose parts lying around, stained and well-worn tools, cars that are half-taken-apart, and the smell of sweat and grease in the air. Being clean is a nice bonus, but it isn’t really necessary.
Github is a mechanic shop, not a dealership. I expect to see broken code, half-finished projects, and little fun experiments that you worked on and then abandoned. I want to see you working on your craft on your Github. A pretty Github is a nice-to-have, but an empty Github calendar can be a turn-off.
If you want other software developers to take you seriously, treat your LinkedIn like a dealership and your Github like a mechanic shop. Never the other way around.
Is it broken? Push it anyway. If it’s abandoned, leave it up there. My Github is a graveyard of dead projects.