Live data from Hacker News

Qualities that I believe make the most difference in programmers’ productivity

antirez.com

311–320 of 321 posts

Re: Qualities that I believe make the most difference in programmers’ productivity

#311
post #222

Earlier quoted context omitted.

> we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself. Wouldn't an even simpler solution be to just use the scrolling built into browsers?

If you need smooth scroll you can't rely on browser support and need to use a library or cook something up yourself. It's surprising how few browsers work with smooth scroll. Today it's basically only Firefox; not even Chrome.

> If you need smooth scroll

Why would I need smooth scroll? All it achieves is slows down the scrolling so it takes me longer to get to where i want to in the page.

Re: Qualities that I believe make the most difference in programmers’ productivity

#312
post #310

Earlier quoted context omitted.

Depends what kind of software you write. Wouldn't want to get into an aircraft that has software written to those standards.

It would be great if programmers got more responsibility with increased skill and experience. But that is often not the case. There are very few jobs for highly skilled and experienced programmers and hackers.

Agreed, as I said - depends on what you write. It's a shame that so much of the industry actually devalues the very thing that got us into this in the first place (presumably not just money, but some love of engineering quality software), degrading the job to be nothing more than "hacking" together something, just to deliver.

It's not just delivering that is important (it is off course), but what is delivered, and if a company's non-techs don't realize and appreciate this, it's a slippery road.

Re: Qualities that I believe make the most difference in programmers’ productivity

#313
post #48

In this thread: mostly people responding to the headline, not the actual content of the article. There's some fantastic stuff in here about how great design is the key to increased productivity. For example: "It is very important for a designer to recognize all the parts of a design that are not easy wins, that is, there is no proportionality between the effort and the advantages. A project that is executed in order…

Great article, as I'm a bit of an old hat myself I'd like to add a few extra categories - Knows how to handle not knowing or getting stuck - some people have a melt down or won't ask for help when they hit a wall or don't know when to push back (we had a vendor that gave us buggy code but kept claiming it wasn't until we pushed back through our management and forced them to let us see the code). Can visualise the pro…

That second addition is not nearly as valuable for creating code as it is debugging it. When you see an error and can pretty much pinpoint where the problem is, just because that's the only place where that error makes sense... That's a lot of time you just cut out of the entire process.

Re: Qualities that I believe make the most difference in programmers’ productivity

#314

Earlier quoted context omitted.

Great article, as I'm a bit of an old hat myself I'd like to add a few extra categories - Knows how to handle not knowing or getting stuck - some people have a melt down or won't ask for help when they hit a wall or don't know when to push back (we had a vendor that gave us buggy code but kept claiming it wasn't until we pushed back through our management and forced them to let us see the code). Can visualise the pro…

Is that really a long-term productivity boost? I wager the cost of maintaining and debugging the vomited code destroys any total productivity advantage. Of course I am completely biased in that I can bold barely anything of a program in my head. I feel like that makes me a better programmer in terms of writing shorter, maintainable code. It's hard to assess yourself honestly though.

"vomit" maybe isn't the best word.

The point is they are able to in their head: compose the program, notice bugs, fix those bugs, possibly tweaking the design in the process.

Basically, they can prefect the design in their head and fix a lot of bugs all before starting type.

Re: Qualities that I believe make the most difference in programmers’ productivity

#315
post #303
post #236

Earlier quoted context omitted.

Not to be a fanboy but I use a Mac and one of the things that they clearly did a huge amount of research and fine tuning on is the scrolling. I can always tell when there's non native scrolling on a site and it always sucks. Maybe I'm out of touch, but IMO the smoothness of the scrolling is an OS or hardware level feature. If somebody's OS or hardware does not scroll smoothly, then clearly it's something that they're…

I'm not talking about manually implementing a virtual scrollable canvas. I'm talking about "make item 19 in that list box visible in the middle of It's display area." I agree that scrolling virtual spaces should be native and hardware accelerated whenever possible, but I think we are talking about different use cases.

document.querySelector('.item-19').scrollIntoView()

Re: Qualities that I believe make the most difference in programmers’ productivity

#316
post #213

Earlier quoted context omitted.

Another great thing here: "Design sacrifice: killing 5% to get 90%." I remember a very specific example of this from Perl 6 development circa 2009. perlgeek (I think) and I had been struggling with coding up the sequence operator for a couple of months. Every time we thought we had it, someone would come up with a case that broke the system again. pmichaud (not sure if it's the same pmichaud here on HN) comes up to u…

I had a similar experience while trying to devise an algorithm to fill up n spots having n-1 soldiers available in the military. So after losing few hours, not being able to come up with any combination that satisfied all conditions I run to the sergeant, explained the problem and he just erased a spot for 24h, changing spec . Suddenly everything fell in to place. Alexander the Great did the same thing in order to so…

I think you'll like George Pólya's How To Solve It. That's one of the methods he prescribed on solving a difficult problem; by gently removing the most difficult part and look at it again.

Re: Qualities that I believe make the most difference in programmers’ productivity

#317
post #54

Earlier quoted context omitted.

Maybe this is the distinction that throws off these "10x programmer" threads: the idea that a 10x programmer produces ten times the amount of code in a given time. The best programmers I have worked with frequently replace thousands of lines of code with hundreds. Programmer productivity is about value delivered, not lines of code.

The best programmer I have ever worked with used to be my boss. When I learned Perl, he had me write a very simple program to monitor some network printers. When I was finished, I showed him what I came up with and it worked pretty well. I guess it was to show me that I was thinking too much like a C programmer, he rewrote my program in about 10 lines of Perl. He was always willing to listen when I had design ideas t…

> He was always willing to listen when I had design ideas that differed from his own. When my ideas were better, he'd incorporate them into our plans.

This is what makes someone a good Tech Lead and/or manager.

Re: Qualities that I believe make the most difference in programmers’ productivity

#318

Earlier quoted context omitted.

Come on, Antirez is a x10 programmer, he coded one of the most brillant software of the last decade. It's so well done I use it as an example in my trainings, making people compile it to stop being afraid of building from source because I know it never fails and it's so damn simple. And programmer reading anything on his blog, or anything on HN for that matter, is not an average programmer anyway. The simple fact you…

So you're saying that 10x developers definitely exist, it's just a disappointing state of affairs. Like how the Turing Test was rendered obsolete because online comments (e.g. Youtube) became so bad, the bar to writing a bot that passed as one of them was lowered dramatically.

Maybe all these "I'm \d+ years old, and I like this song" before each old* song were written by bots. This would explain a lot.

*old song, according to Youtube comments is every song recorded before 2016 AD.

Re: Qualities that I believe make the most difference in programmers’ productivity

#319
post #160

Earlier quoted context omitted.

"great design is the key to increased productivity" Given how many times the 90/10 principle will brutally murder your time estimates ("we're 90% done, so there's only 90% left to go!"), learning to also harness it in your favor as antirez talks about is a great programmer differentiator. If 90% of the effort is coming from 10% of the design, and you can find some way to cut that part of the design in half, you just…

At one of my first jobs, my employer had $1.2MM and 10 people budgeted full time for 2 years to build a project that would allow managers to make queries on a very large dataset. I pored through the specs, talked to everyone who would use this, and realized all the queries could be calculated from a much smaller, summarized version of the data. I wrote a script that would create an Excel PivotTable every month and se…

It's amazing how much time and money one intelligent person with ideas can save a company if their ideas are actually able to be implemented.

I hope you ended up seeing some of that $1.2M, yet somehow I doubt it.

Re: Qualities that I believe make the most difference in programmers’ productivity

#320
post #43

Earlier quoted context omitted.

I've also seen negative impact developers. If they did not code, we'd be closer to the finish line than if they did not. Works great if you pair them with a more senior developer who has the chutzpah to make an impact by deleting egregiously bad code. E.g. one of the best I know made a failing project succeed by literally deleting all unit tests (which in that case were not providing value at all).

Failing project or failing project tests?

Failing project: the tests were the impediment (too broken and costly to refactor, every change would cost more in unit test fixing than actual implementation).
Post reply on HN