My guiding principles after 20 years of programming (2020)

>They d,o but your boss doesn't

You don't know. You don't work there. You're just making stuff up to bolster your position. Users never complained about the speed of the system based on that algorithm.

>Yes and you're not the only one but the "I've been burned therefore noone can use 3rd party libs" is childish.

No one said that but you.

>is childish

If you can't attack the position, attack the person, right?

Well we'll just have to agree to disagree. I'll run my team how I see fit and you run your team how you see fit.

Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks.

Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway.

To be sure, I do a little whiteboarding, but generally it might be about 2 hours or so of sketching out ideas, major structures, code flow ideas.

I generally was nodding along to most of the author's points though.

I definitely have grown to divorce myself from my ego and always try to not only try to shine the spotlight on my younger coworkers (new engineers) but try to give them "ownership" of key pieces to allow them not only some sense of autonomy/ownership but a sense of pride as well.

That does go slightly against some of the author's points about collaboratively working on a project. Engineers need a part of the code (let's say an image cache manager, as an example) that they can "own" though in order to grow. You don't want an engineer to always have "training wheels" on. (And frankly, I think this is one of the things I dislike about code reviews, I think it dis-incentivises autonomy.)

The team though, let me be clear, is the most important part of any project, not the individual luminaries. The "team" though, to a degree, needs to have engineers who feel an ownership stake in pieces of the product.

(FWIW, I have probably 35 years of programming experience, ha ha.)

I think it's key to think about the wording here

> understand the problem

> code-test-improve cycle

I think you're first trying to understand a non-programmatic problem, a business problem, a user problem. Then you start to explore the solution to that problem. Yes, you'll learn more about the "problem" as you solve it, but the cycle explores how you're solving the problem.

All good guidelines. A corollary to 1) don’t fight the tools, use the right tool is that you have to know lots of tools. Or at least, enough of several tools to know when to pull out which tool. Otherwise, “if all you have is a hammer, all problems look like a nail”.

I implement this by reading industry news, “spiking” projects for interesting frameworks, ides, etc. I find it helps to go broad in learning- learn a little about lots of things, but then deep dive when interest or need arises.

It should be easy to talk a pointy-haired boss (PHB, see Dilbert) into "readme-based development" (RBD). In fact, you can probably get funding for training, aka pizzas.

That's because RBD is basically Amazon's "write the press-release first" methodology and no PHB will say "we won't use something that Amazon says makes them successful."

The pizzas come from another Amazon saying.