Hacker News Reader

Comment by Waterluvian | Hacker News Reader

This misrepresentation of what writing is, is something I very commonly see in software. People often think software dev is about coding.

In reality, while software developers probably enjoy the act of coding, it’s rarely the interesting or difficult part. It’s just the rendering you do to bring all the work you did to life.

View on HN

As I've progressed in my career, I find this to be more and more true. I would say most days I spend only 50% or less of my time writing code. Even when I do write code, the volume isn't huge. The challenges for me these days is in evolving existing systems without disrupting the business and designing and then implementing things that people can build on top of. The work is still very technical but a lot of it involves researching and planning and testing out hypotheses.

Even with "just coding", a skilled coder can translate thoughts directly to code more precisely and faster than translating them first to imperfect English.

I still have to find a programming language that allows me to convey all the nuances of my thoughts and considerations only through code (and keep it readable and concise). This is why there there are few (no?) languages that don't allow for comments in natural language.

The original-ish Lisp had no comments I believe. The workaround was a nop "comment macro" though.

I guess it was more common in the card data days where you could write comments by hand on the card.

I know it sometimes feels easier to just implement something than file a JIRA ticket with enough detail to describe what needs to be done.

The first hard problem is to understand what to build. The second hard problem is to build it in a way that is clear and maintainable.

I wouldn't discount the importance of clarity in the way you code. You might end up writing the right solution, but because you didn't communicate "what", "how", and "why" clearly enough in your codebase, you will setup other developers (and potentially the business) for failure.

Coding is also a part of why coders get paid so well. It's certainly true that software developers have other skills too, but how those skills are distributed among the general population can't be known so long as coding remains an entry barrier for most people.

It's also possible that not all devs have the same qualities, and each one finds the niche that works for what they bring to the table.

My experience is that "coding skills" are the intersection of analytical (being able to formulate hypothesis and test them) and language. There's a (small) barrier to entry. That and the lack of any gatekeeping is why we saw the explosion of Coding Bootcamps "become a javascript engineer in 12 weeks". Even tough the great majority of people attending these camps won't be able to write a single line of code at the end of the program, a few will be able to grasp it enough to fill in the blanks on a template for a website or an app.

We also had language models that could generate code out of very precise specifications back in the 90's. They were called offshored programmers. Send an email in the evening and get a .zip file in the morning with code. Sometimes it would even compile!

Engineering is much more than that. It's about being able to formulate, understand and analyze (conflicting) requirements as well as the ability to gain domain expertize as needed. The best example of that is Carmak and binary space partitioning. [0]

To me, what GPT is going to achieve with it's current performance is akin to what compiled and interpreted languages did: You no longer really care about word size, endianness or alignment issues. The compiler takes care of generating the correct assembly for you. Same thing with snippets generated with GPT.

[0] https://fabiensanglard.net/quakeSource/quakeSourceRendition....

Reply on news.ycombinator.com