speed alone doesn’t make someone a good programmer. experience and knowledge of craft is what allows one to work more efficiently and quickly.

Fast == bugs

You have to be a peculiar kind of stupid to get that causation backward.

This dude should rename himself to “Dumbroy”. Wants to write a blog, but cannot analyze for shit.

Fast is good? Work in small chunks of time?? Þis person has never held a programming job before. It it AI?

Most of these takes seem pretty agreeable to me. I would push back on the premise a bit in specific cases, like when you have a manager that always seems to want something new and changes their mind all the time. You need to insulate yourself from that stream of wasteful work by just not doing it until it’s obviously necessary.

Yeah, there’s several silly metrics for management to judge programmers. It’s mostly because management needs some oversimplification, because they have no clue what programmers do all day.

Most common one is “lines of code” (LoC) written in a day. Of course you’re making the company more money if you write more code. That’s your job after all, right? Right?!?? …Of course that punishes people who write efficient code. Who think first and then come up with a smaller, better to maintain version.

It’s similar with speed. But just tell the programmers what to do! It’s easy to get 80% the way with 20% the effort. That’s how it always works. Your programmers can do that, just write it into the project specification.

But to be honest, the major time factor isn’t writing code. It’s all the project management. Misunderstandings, specifications which change over time. Additional requirements after the fact. That’s the major time waster in software projects. Typing down the code takes time as well, but it’s usually not where projects go sideways.

And use some good frameworks. Leverage someone’s wisdom. Also a major time waster if you wrote code for 2 weeks and find out you’re using the wrong framework and need to start over.

(Oh boy, and please don’t take the advice to send in half-baked PRs. Yeah, that might look like you’re done sooner. But that’s gonna waste somebody else’s time. And it’ll inevitably return to you and then you’re gonna put in some more time anyway. And you’re gonna waste some more time on arguing about details, changing around stuff… Just get it done on the first try, without any additional back and forth. And returning to each problem three more times. That’s the way to move quick. The outlined way is again how to make management happy. They LOVE to see a PR early and then a lot of activity in the comments. Looks like it’s complicated and people are very busy. But they’re most likely only adding noise and unnecessary back and forth. It’s just… if you just get done with it, quick and without any fuss, nobody will notice.)

The only times I recall being very fast with something were when we were fixing prod the next day

value = speed x quality x volume

Work fast; produce high volumes of shit.

In my country, they say that you need to be fast when catching fleas. They also say, I can type 2000 characters per minute, but the result is a total bullshit.

I can be very fast when working on the project that I know very good. An I can be very slow when I need to understand how the code works, to learn some new API, new tools etc. If I always were fast, I’d make a lot of stupid mistakes and had to fix them wasting much more time than I spent for initial investigation.

Best paid or best quality?