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

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

antirez.com

Post reply on HN
Print view View original

291–300 of 321 posts

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

#291

Post by lacampbell »

Debugreality wrote: post #275
simonw wrote: 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…

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.

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

#292

Post by lacampbell »

avereveard wrote: post #252
cabalamat wrote: post #146

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?

Because while default scroll is fine for scrolling pages whole, in any scrollable div that's not top level it looks out of place like a blacksmith on an iceberg. It's a gray slab that looks like a tombstone riding a straight, dull rollercoaster and unless your site makes a point of having a '90s inspirational look there's no way to integrate them in a page so that it doesn't feel completely detached.

If I was in your team I would be saying "why not just scrap scrollable divs?".

I am always looking for excuses to get rid of stuff.

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

#293

Post by odbol_ »

neutralid wrote: post #223
simonw wrote: 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…

> 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. In optimization, if you make an analogy between speedup / improvement with advantages / effort, you get Amdahl's Law: https://en.wikipedia.org/wiki/Amdahl's_law "[T]heoretical speedup of the execution of the whole task increases with the impro…

So you're allowed to name laws after basic common sense now?

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

#294

Post by Debugreality »

lacampbell wrote: post #291
Debugreality wrote: post #275

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.

It's true the resulting code isn't perfect. But there are design advantages to holding the code in your head that make up for sloppiness at least that was my observation. A code review for error checking is certainly advisable and good practice to boot!

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

#295

Post by taneq »

jakobegger wrote: post #276
gav wrote: post #270

Earlier quoted context omitted.

Finding a better solution by changing the problem is great, especially as the problem stated is often not the problem faced. Not doing something, or doing something dramatically simpler, ends up with less code being written. The cost of writing the code is usually a small fraction of the cost of supporting it during over the life span of the system. One problem I faced was a client that as part of an e-commerce re-im…

This is the difference between a real programmer and a coding monkey. Coding monkeys consider the spec the problem and try to write code that solves it. Programmers consider the spec a part of the solution and evolve it as necessary.

"The problem is not the problem, the problem is your attitude towards the problem." - Jack Sparrow

So many times I've seen someone struggle to implement a poorly written spec rather than just say 'hey can we just do X instead?' If X solves the REAL problem then sure you can.

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

#296

Post by Spooky23 »

antirez wrote: post #168
Spooky23 wrote: post #134

Earlier quoted context omitted.

In defense of those people, the layout of the site is actively hostile to people on mobile. -10x for readability.

I'm sorry, for the kind of things I tend to blog about, monospace font was the simplest way to have a truly what-I-write-is-what-appears without using any markup. If I could start from scratch I would use MarkDown, however at this point if I switch all the past blog posts will be broken, or I should switch conditionally from a post ID >= but then the blog will be a bit inconsistent. I'll try to figure out a solution.

Personally it wasn't the font for me but the way it wraps. I have some annoying vision issues that pop up from time to time. My solution is to use Safari reading mode on iOS, but that made it worse in this case.

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

#297

Post by solipsism »

dlwj wrote: post #288
omnimike wrote: post #287

While I completely agree that some programmers can be 10x more productive than other ones, I think it's far more common to see programmers who LOOK 10x more productive than others. It's very hard to compare people who have different problems to solve. Solving 90% of the problem is not the same as solving 100% of the problem, and sometimes that 10% really is worth the effort. I've seen cases where one ostensibly 10x d…

"I came, things got better, I left, things got worse. What do you think that says about me?" Whether it's an engineer, or a manager, or C-level executive, this is very easy to achieve by borrowing from the future. Very difficult to solve I think.

You forgot politician

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

#299

Post by lacampbell »

Debugreality wrote: post #294
lacampbell wrote: post #291

Earlier quoted context omitted.

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.

It's true the resulting code isn't perfect. But there are design advantages to holding the code in your head that make up for sloppiness at least that was my observation. A code review for error checking is certainly advisable and good practice to boot!

but the thing is the poor person finding bugs or adding features in the code is going to spend 2x as long. and then 2x as long the next time, and the next time... "no we can't re-write it, it's working code! just add the feature...".

If Mr. 4x had slowed down a bit and written something more structured, the overall cost would have been less, surely.

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

#300

Post by Debugreality »

lacampbell wrote: post #299
Debugreality wrote: post #294

Earlier quoted context omitted.

It's true the resulting code isn't perfect. But there are design advantages to holding the code in your head that make up for sloppiness at least that was my observation. A code review for error checking is certainly advisable and good practice to boot!

but the thing is the poor person finding bugs or adding features in the code is going to spend 2x as long. and then 2x as long the next time, and the next time... "no we can't re-write it, it's working code! just add the feature...". If Mr. 4x had slowed down a bit and written something more structured, the overall cost would have been less, surely.

No nothing like that at least the couple I've worked with. I think you are confusing these people with "coding minds" with people that can churn out working code quickly (they are a different beast). The code produced by the 4x people is very elegant structurally because they can see how it fits together, this is the strength but it may be missing some edge cases / functionality and or validation in the first pass.
Post reply on HN