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

261–270 of 321 posts

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

#261

Post by codr4life »

xyzzy4 wrote: post #211
codr4life wrote: post #150

"When the task at hand is much more rigid, with specific guidelines about what tools to use and how to implement things, the ability of a 10x programmer to perform a lot of work in less time is weakened: it can still exploit “local” design possibilities to do a much better work, but cannot change in more profound ways the path used to reach the goal, that may include, possibly, even eliminating part of the specificat…

Reminds me of when I used to work at Cisco. All the software there for routers must be written in C. As a result everything takes much longer than it should.

It always seemed weird to me to hire expensive specialists only to slap them around and override their experience by insisting on sub-optimal tools, methods and work environments. It took me 30 years of diligent, daily practice to get here. That experience better be put to good use or I'm out, I have no patience for business bullshit.

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

#262

Post by DougWebb »

fastbeef wrote: post #238
DougWebb wrote: post #197

Earlier quoted context omitted.

I'm proud to say that I've accomplished that, at least once. My company was developing a new feature, hundreds of medical textbooks that would be searchable and readable online. The source content for each textbook consisted of a huge xml file and a bunch of images. The problem we faced was that many of our customers were government-funded libraries, and they required a physical product for anything they purchased. (…

I hope you were handsomely rewarded for saving the company tens of thousands of dollars, if not more.

Hundreds of thousands, probably, and my work on that textbook feature brought in millions in revenue. Another aspect of the project is that I wrote a custom XML content storage and retrieval database, and spending a couple of months proving that my solution was far more scalable and performant than either the Oracle-based solution or commercial XML database solution that the director of development and CTO preferred. So I saved the company a 6-7 figure annual licensing cost as well.

My reward was short-lived immunity to the corrosive political environment that the CTO and director of development had created. The director came from a competitor we had acquired for their customers (not their tech), and right from the start he was open about wanting to eliminate our development team so that his old team could be in charge. They failed due to incompetence, and he and his entire team were let go some years later. The CTO lasted longer, eventually firing my manager without cause, and I quit a few months later. The overall product we were responsible for (which the textbooks were a part of) is still running, and it is still their flagship. But very little has been done to it in the past seven years since I left. The CTO was let go a year or two after I left.

Handsomely rewarded? Hardly. That's not how it goes in big corps. Presiding over the hand-off from the team that was let go was satisfying, and knowing that my software is still running strong after many years of neglect because everyone who was capable of maintaining it quit is also somewhat rewarding.

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

#263

Post by [deleted] »

fastbeef wrote: post #238
DougWebb wrote: post #197

Earlier quoted context omitted.

I'm proud to say that I've accomplished that, at least once. My company was developing a new feature, hundreds of medical textbooks that would be searchable and readable online. The source content for each textbook consisted of a huge xml file and a bunch of images. The problem we faced was that many of our customers were government-funded libraries, and they required a physical product for anything they purchased. (…

I hope you were handsomely rewarded for saving the company tens of thousands of dollars, if not more.

[deleted]

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

#264

Post by T-hawk »

unoti wrote: post #222
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?

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.

What web page or application would need smooth scrolling? What can't work with whatever scrolling is normal for the browser/OS/hardware?

Looking cool at the request of some manager does not constitute a need.

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

#265

Post by z3t4 »

Being able to see edge cases and bugs before they happen will kill your productivity. I think the hardest part is to ignore those and deliver. If no one uses the software, then no harm done, and if the software get popular you will hopefully get funds to pay back the tech debt.

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

#266

Post by petra »

thr0waway1239 wrote: post #260
petra wrote: post #255

Earlier quoted context omitted.

For enterprise software(and some IOT) Mendix and outsystems are the leaders, but there others : http://agilepoint.com/wp-content/uploads/Q2-2016-Forrester-L... For the IOT, i believe thingworx is the leader.

HN is a bubble for sure, but that may not be the reason why low-code tools are not discussed. Suffice it to say that my interest got less and less piqued with every single word in the URL you provided (I was already biased against it before even reading the report), and I couldn't get past the first few pages in the PDF before feeling bored. I recently was looking for Java based open sourced wiki software for intrane…

The link i gave is to a report. It's boring. But it's comprehensive and lists all the platforms and a good starting point, because someone asked about that.

But the issue itself is more interesting: first - it's a big and relatively common software design problem(for example see how often visual "coding" is discussed) - how to enable common people to build complex systems. So what are the approaches being tried ? How are the better/different/worse/etc ? what could we learn from them ?

Second - what does it mean to the software engineering profession ? to freelancers ?

Third - what are the implications to entrepreneurs ? what kind of new opportunities does this open ? could this make large corporations agile enough to make it hard for startups ? what are good strategies ?

On the other hand, often you see here discussed some toy programming language that someone made(which is a cool project), but the improvements are quite small, the implications are quite small, and the major reason people find it so interesting is the bubble.

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

#267

Post by andrey_utkin »

ram_rar wrote: post #257
colomon wrote: post #156

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 wish somebody writes a book accumulating such stories. Nothing excites me more than learning from history.

Check "The Art of Unix Programming" by Eric Raymond. It's full of exciting stories from computing pioneers epoch, and more than that, it's just filled with empowering inspiration about simplicity. To quote just one story from this book:

> One epochal example not mentioned in Gabriel's paper is from distributed hypertext systems. Early distributed-hypertext projects such as NLS and Xanadu were severely constrained by the MIT-philosophy assumption that dangling links were an unacceptable breakdown in the user interface; this constrained the systems to either browsing only a controlled, closed set of documents (such as on a single CD-ROM) or implementing various increasingly elaborate replication, caching, and indexing methods in an attempt to prevent documents from randomly disappearing. Tim Berners-Lee cut through this Gordian knot by punting the problem in classic New Jersey style. The simplicity of implementation he bought by allowing “404: Not Found” as a response was what made the World Wide Web lightweight enough to propagate and succeed.

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

#268

Post by sheepmullet »

kasey_junk wrote: post #140
sheepmullet wrote: post #130

Earlier quoted context omitted.

> So sure, there are developers who are better than others, maybe even in non-linear ways, but so what? The fastest way to kill high levels of productivity is to not value high levels of productivity. Edit: And I believe there is a strong correlation between people who value high levels of productivity and people who can build highly productive work environments.

> The fastest way to kill high levels of productivity is to not value high levels of productivity. I have not found that to be true. In my experience the fastest way to kill productivity is to measure it incorrectly & incentivize bad behavior chasing the wrong thing. Everyone values productivity but virtually no one has a good way to measure it, at least not in software.

> In my experience the fastest way to kill productivity is to measure it incorrectly & incentivize bad behavior chasing the wrong thing.

In my experience this is almost always a management driven attempt to turn 1x engineers into 1.2x engineers.

Can you provide some examples where this is the norm in a company culture which focuses on building and enabling high performers?

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

#269

Post by mikulas_florek »

squeaky-clean wrote: post #246
mikulas_florek wrote: post #210

Earlier quoted context omitted.

I do not think Notch have more programming experience than thousands of other programmers in the industry. He worked on games professionally only for 9 years. Minecraft is not that technologically great, it's just a fun game to play and very famous.

> Minecraft is not that technologically great, it's just a fun game to play and very famous. But that's the point. Kids aren't going out of their way to buy complex technical achievements. They want a fun game. They don't care if it's 30 mil lines of beautiful C or 200k lines of ugly Java. > I do not think Notch have more programming experience than thousands of other programmers in the industry. Where and how you us…

Yes, I guess you are right in a way. One can become 10x game jam programmer simply by attending a lot of game jams, but be average in normal gamedev job. And Notch might be one of those 10x game jam programmers, I do not know his work in this area.

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

#270

Post by gav »

colomon wrote: post #156
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…

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…

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-implementation brought a huge list of requirements for promotions and how they should work. There was hundreds of use-cases, some being very complicated.

I came back to the client and said, "are you sure you need all of this?" After working with them to investigate, it turned out that they had just documented all the features of their existing system. In the previous ten years, they had created exactly one coupon, and that was for a flat 10% off.

That was the functionality we initially went live with.

Post reply on HN