Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1x Programming

tim.mcnamara.nz

Post reply on HN
Print view View original

191–200 of 217 posts

Re: 1x Programming

#191

Post by stackbutterflow »

saila wrote: post #138
torginus wrote: post #109

Earlier quoted context omitted.

Unfortunately (or fortunately) there certainly are 10x engineers, and if they happen to be your coworkers, that's the most amazing thing in life. It's the difference between handing a task over to someone, and finding next day that it's done in amazing quality and finding they haven't made any progress at all. And in my experience, these people usually are not braggarts or have huge egos, they are just really good at…

Another huge factor is that some people actually enjoy programming, which is not to say there's anything wrong with people who don't, but when you're having fun writing code it's going to be much easier to be productive than when you view every task as a slog, and it honestly seems like there's more of the latter than the former. Again, I want to emphasize that there's nothing wrong with being a programmer who's not…

it honestly seems like there's more of the latter than the former. Probably people who went it programming for the money in the last decade. I can't imagine writing lines of code everyday for years if it's something you dread.

Re: 1x Programming

#192

Post by manmal »

ratww wrote: post #71
manmal wrote: post #68

Earlier quoted context omitted.

Is that really a thing, secretly working more to give the appearance of higher output, while not even getting paid for it? Given the little time we have on this planet, this sounds like a suboptimal use of it.

It definitely is. It happens with over-achievers but it also happens very frequently with under-achievers. In jobs where people have quotas it is very visible, seeing people scrambling to finish it all by the end of the month, to the detriment of their free time. But this is also the "secret" of some over-achievers. It's absolutely unhealthy.

I think I'd rather invest the extra time into OSS or a hobby project, which, even if you only do it for vanity, might even look more impressive to others.

Re: 1x Programming

#193

Post by davidatbu »

Floegipoky wrote: post #135
davidatbu wrote: post #21

> Synthesis is essence of software engineering, whereas abstraction is the essence of computer science. Your job as a software developer will be to synthesise something new from composable pieces. What you create should be simple to understand and extend. Loved this.

It's a nice quote, but I really disagree with this section. Yes, software development is more concrete than computer science, but abstraction is so, so important. The author acknowledges the value of simplicity, but simple code is only produced by choosing the right abstractions. Getting even 1 key abstraction wrong can create enough "friction" to eventually kill a product if the tech debt isn't managed well. 99.5% o…

Agreed that the quote, in isolation, undersells the importance of abstraction in software dev.

Re: 1x Programming

#194

Post by ratww »

Sodman wrote: post #137
ratww wrote: post #94

Earlier quoted context omitted.

I find these stereotypes very reductive, and having a bit of prejudice. Being unproductive is not a guarantee of having good communication skills, and likewise being being highly-productive is not a guarantee of being bad at communication. If communication is part of the job, in the case of seniors mentoring juniors, for example, then lack of communication skills would definitely prevent someone from being a "10x".

I think a big contributor to this "Brilliant asshole" trope is that if you ignore some things like teamwork/communication it's a lot easier to appear to be doing 10x the work. This can manifest in so many ways... Not doing any code reviews? Leaving tests "for somebody else to write"? Refusing to work on legacy code-bases and only working on greenfield projects? Tuning out (or just not even joining) API design meeting…

Yeah, this is similar to the "10x, but they work twice as many hours a week". It's not someone who's more productive, it's just someone who manages to be more productive by making everyone less.

Re: 1x Programming

#195

Post by ratww »

Xeronate wrote: post #169
vlunkr wrote: post #148

Earlier quoted context omitted.

> Basically the general rule is if you desire above average money, you have to put in above average effort at some point in your career. My (probably cynical) take is that most SV devs are also 1x. You make the big bucks not just by being a 10x dev, but by some combination of going to the right schools, making the right connections, learning how to negotiate and when to look for new jobs, learning to jump through the…

Jumping through big tech interview hoops is the most correct part of your statement and it invalidates the idea that you ned to go to the right school or have the right connections. And for what it's worth, the average FAANG developer I've worked with has been much better than my colleagues at prior companies.

> And for what it's worth, the average FAANG developer I've worked with has been much better than my colleagues at prior companies.

I worked at a FAANG and I'd agree with that: the people there were good. But there was a huge caveat: most of them were definitely doing what would be "1x work" in a non-FAANG jobs. FAANG is very good at hiring but not too good at using the people to their full potential.

Re: 1x Programming

#196

Post by ratww »

emodendroket wrote: post #91
angarg12 wrote: post #25

I praise 1x programmers, but for reasons that might go against the grain in HN. I'm from Spain so our working ethic is different from the Anglo-Saxon world. "Work to live, don't live to work" as the saying goes. My principles for a 1x programmer: * Work is a means to an end. A job should support the lifestyle you want to achieve, not be an end on itself. * 9-to-5 is a perfectly reasonable schedule. Fiercely protects…

I don't want to do excessive overtime (or overtime at all if I can help it, but I'll make an occasional allowance). But I also don't really want to be sitting around during the workday without things to do. That's its own kind of unpleasant experience, to me.

> But I also don't really want to be sitting around during the workday without things to do.

Funnily enough, that was my experience working for a FAANG and a couple startups that had just recently gotten a lot of investment money. They need 300 developers, and only the best, but they're a bit disorganised and don't have enough work for all devs. Lots of sprints finished three days earlier, lots of digging holes and filling them back.

And you're 100% right that it sucks.

Re: 1x Programming

#197

Post by ratww »

runald wrote: post #182
ravedave5 wrote: post #103

Earlier quoted context omitted.

I'll never forget having a negatively productive programmer on my team. If he spent an hour on a PR it would take 1.5+ hours of work to get the PR into shape to merge by other people because it took so much explaining for this guy. It was usually better to just scrap his code and start over. If code of his did slip through reviews often times there would be production defects that would then take more time to solve (…

I heard of a creature like that. I think they are called human being. Someone who was assigned to a team of highly efficient robots that never make mistakes and produces bug-free code. Production defects? Yeah, it's obviously that guy's fault alone. /s If I didn't know any better, it sounds like you are just using the guy as someone to conveniently blame.

I disagree with that, it really isn't "normal" to have someone like that, but it does definitely happen. Doing a crap PR once in a while is absolutely normal for everyone, but doing that regularly isn't.

This is clearly someone who is working beyond their abilities, and needs help and mentoring.

This is not the person's fault, though, this is a management issue, and maybe also a cultural one, where people just assume this person "should know" just because they've been at the company for a long time, and mentoring would be "beneath" them.

Re: 1x Programming

#198

Post by axxto »

systemvoltage wrote: post #124
angarg12 wrote: post #25

I praise 1x programmers, but for reasons that might go against the grain in HN. I'm from Spain so our working ethic is different from the Anglo-Saxon world. "Work to live, don't live to work" as the saying goes. My principles for a 1x programmer: * Work is a means to an end. A job should support the lifestyle you want to achieve, not be an end on itself. * 9-to-5 is a perfectly reasonable schedule. Fiercely protects…

I’m the complete opposite as far as it can be. Work is life. I don’t want to spend a third of my life on something that’s just a “means to an end”. It is me. It is mine. It is my expression. It’s the result of everything I’ve got to give to this world. So, to each, their own. This game is better played when you have skin in the game (equity, control, recognition).

> This game is better played when you have skin in the game

I think framing a life as a "game", which implies that there is a specific goal upon which one can either "win" or "lose" is the core of your disagreement with that particular way of thinking. Some people see things as more of an open-ended, "freestyle" exercise, rather than a win-or-lose plan

Re: 1x Programming

#199

Post by isaachawley »

Nice article. I wouldn't call this approach "1x Programming." This is more about how to be a net-positive member of a dev team.

As a longtime dev and recent dev manager, I hate most self-described 10x coders. I want people who are net-positive. Team players, focused on adding value, doing unsexy work, keeping the build and tests green. Being nice to each other.

Even if they're barely productive, as long as they're net-positive I'm perfectly happy having them on the team.

Re: 1x Programming

#200

Post by ratww »

Trasmatta wrote: post #133
ratww wrote: post #73

Earlier quoted context omitted.

At several companies I worked for, by using Scrum Points, it was always visible that the most experienced devs were able to regularly deliver a multiple (definitely around 10x) more points than interns and about 2x more than the average dev. Not a perfect metric by any means, of course, but definitely quantifiable and observable. Metrics for LOC and commits/PRs made also followed a similar pattern. Again, not perfect…

Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories? Or estimating story points vastly differently than other members of the team? In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures.

> Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories?

Your objections make no sense.

If a story is easy but the number of points is not reflecting the ease, then the estimation is wrong, period.

If there is someone on a team with such an estimation superpower so that they're able to know which tickets are easy, then just make this person estimate all the tickets. Problem solved.

You either accept that someone is more productive, or you accept the estimation you performed is wrong by a factor of 2x. You can't have it both ways.

> Or estimating story points vastly differently than other members of the team?

In all the teams I worked the estimation was done by the entire team. If it's not being done by the whole team, then there's no real baseline to compare the work being done by two people, period.

> In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures.

The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint).

Post reply on HN