Would it be possible to create a programming language that allows you to write branching programs, but is guaranteed to compile it into branchless code?
It brings Steve Jobs' quote to mind: "It doesn't make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do"
Companies who generically look for "the best engineers" think their problems will be solved if they can just hire someone smart and tell them what to do. They say they want "the best engineers" but then their job descriptions and interview processes scream "we want someone who will execute our vision exactly as we've defined it."
The best engineers will tell you why your architecture is wrong, why your code sucks, why your timeline is unrealistic, and why your product decisions make no technical sense. If you're not ready for that level of pushback, you don't actually want the best engineers.
>The best engineers will tell you why your architecture is wrong, why your code sucks, why your timeline is unrealistic, and why your product decisions make no technical sense. If you're not ready for that level of pushback, you don't actually want the best engineers.
Then they'll help you figure out how to get where the company needs to be, on a feasible timeline, with the resources available.
> We hire smart people so they can tell us what to do
Or from Bell Labs: "How do you manage a bunch of geniuses? You don't"
> Companies who generically look for "the best engineers"
If you need "the best" then your system is (most likely) too complicated and you're going to have a hard time keeping "the best" as their work becomes frustrating.
> The best engineers will tell you why your architecture is wrong, why your code sucks, why your timeline is unrealistic, and why your product decisions make no technical sense. If you're not ready for that level of pushback, you don't actually want the best engineers.
I want to stress how important this is. An engineer should be grumpy. The job is to find problems AND fix them. They don't just complain but argue why it should be done another way. They complain about what seems like petty things because they understand that if a big problem can be broken down into small problems than the accumulation of small problems creates big problems.
People often conflate phrases like "but what about", "how do we handle", "okay, but" or so on as "no". But these are not "no" phrases by engineers. These are "I'm thinking out loud" phrases.
If you surround yourself with yesmen you've surrounded yourself with people who don't care about the company, they just care about their own survival within it. Unless you're perfect, you need people that are unafraid to challenge management when they think management is wrong. You need people to be able to make mistakes because hindsight is a million times clearer than foresight.
Not just that, it's also "I want to know what your opinion and reasoning is on this as well"
This has often led to some of the most productive conversations of my career.
> This has often led to some of the most productive conversations of my career.
Same! Often the conversations I've learned the most from are about topics I already think I know a fair amount about but someone mentions some seemingly tiny detail that ends up changing everything. These conversations tend to stick with you long after they're held, as you have to keep updating so many other beliefs lol
Which is to say, collaboration is an incredible tool. You have a lot to gain by knowing others know more than you about certain subjects. This can even come from a very junior person. It's less common, but sometimes they ask a question that they often think are dumb but throws a wrench in everything. (Juniors, speak up. Worst case seniors should use those as teaching moments. Best case, you look like a genius. If seniors get mad, start applying elsewhere (unless you really are holding up a lot of conversations))
I'll heartily agree with that but will point out that Jobs was absolutely famous for believing his opinion was the only correct one, micromanaging anything that caught his interest, and routinely chewing people in public out over unimportant details and simple mistakes. So, great sentiment, not a great example. :)
My favorite company I ever worked for was much like what you describe. The management attitude from top to bottom was, here's what we think we need to succeed in this market, tell us what you need to get it done and we will give you the freedom to do it. There was a culture of people fixing small but annoying bugs in between major feature work, prototyping ideas that would make all devs' lives easier, and strong communication within and between teams. You were never chastised for dropping everything to help someone else get unblocked. People were nice to each other and were even not afraid to engage in a little light humor now and again.
It was profitable even throughout the great recession but could only scale to a certain point. So the founders decided to get out at the top and sold it to another company that didn't know what to do with it and most of the good people left when the culture changed to more traditional top-down management.
reply