Live data from Hacker News

Build full “product skills” and you'll probably be fine

twitter.com

651–660 of 829 posts

Re: Build full “product skills” and you'll probably be fine

#651

Earlier quoted context omitted.

OP said “product manager” which is also wrong. Funny how these three very different roles constantly get mixed up by smart engineers.

Maybe because from the POV of engineers, they all look kind of the same and half of it doesn't make sense.

The bad version of all three look exactly the same. And the bad version of all three are actually worse than nobody at all. Yet, high management is completely convinced those people are essential so they'd rather keep a bad professional there than get rid of them.

Anyway, the good version of those three are completely different, and add a ton of value on very different places. I think they are rare enough that many people don't ever meet one of them.

Re: Build full “product skills” and you'll probably be fine

#652
Real Artificial Intelligence? Yeah, that would definitely factor out a lot of the wasted work we call "engineering".

Language Learning Models like GPT? Not even close.

We should absolutely stop calling those "AI". They are not intelligent. They model intelligent behavior: human writing.

We should probably even stop calling them "Language Learning". They don't know or care what language is: they learn whatever patterns are present in text, language or not.

Text contains the patterns that humans identify as language; but those aren't the only patterns present in text: which means language is not the only thing being modeled by an LLM. There is no categorization happening either: a pattern is a pattern.

There is this religious cult surrounding LLMs that bases all of its expectations of what an LLM can become on a personification of the LLM. They say that we can't possibly understand the limitations of this method; therefore there are no limitations at all! It's absurd.

Re: Build full “product skills” and you'll probably be fine

#653

Earlier quoted context omitted.

I agree with your characterization in general. If all someone has is an idea and no relevant experience to back it up, run. I can’t stand people like that. But there’s one type of ideas person I’m thrilled to work with. Someone with deep and successful experience in sales. The head of sales at my company is also relatively product oriented and boy, he just has a knack for what customers want. In general, I think many…

Besides opening your own company does a role exist where you can do both?

In my company, all of our sales people have a technical background. They are not the best engineers in the company, but they could do the job if they had to. More importantly, when faced with technical people, they are not completely clueless.

Re: Build full “product skills” and you'll probably be fine

#654
One of my (many) related concerns is that a lot of startups have seemed to be some degree of investment scam (and not just the blockchain ones) -- where all the engineering was oriented towards appearances, rather than viable business/product.

I think that shaped the thinking of a lot of people, of how product and engineering works, whether or not they knew they were working on more a MacGuffin than a business.

Re: Build full “product skills” and you'll probably be fine

#655
post #29

Looking back we had one CS professor who in 2007 predicted we'd all be jobless in ten years, i.e. 2017. His prediction was based on the trends he was seeing at the time. But it wasn't even AI. Instead he made this prediction because he saw the rise of no-code tools replacing software developers because managers could finally cut out the pesky "translators", i.e. software developers. I said it then and I will say it n…

What you describe is the barrier of entry being lowered, as opposed to positions being eliminated. Fully agree.

Think about the difference between Assembly and Python. Programming will continue to get higher level. Perhaps it won’t be so foolish to ask a truck driver to “learn to code.”

But here is an even more interesting comparison: the salary of someone writing assembly 30 years ago and someone writing Python today. Higher level != paid worse.

Re: Build full “product skills” and you'll probably be fine

#656

An average programmer's main job is to track down and fix bugs that shouldn't exist inside software that shouldn't exist build on frameworks that shouldn't exist for companies that shouldn't exist solving problems that shouldn't exist in industry niches that shouldn't exist. I'm 100% convinced that, if someone comes along and creates something that actually obsoletes 95% of programming jobs, everyone would very quick…

I’m leaning in this direction too. I saw someone on Twitter phrase it quite well: “You can believe that most jobs are bullshit [jobs]. And you can believe that GPT-4 will completely disrupt the job market. But you can’t believe both.”

It's rather that the jobs (not the workers) are replaced in the way saddle makers were replaced by mechanics.

Re: Build full “product skills” and you'll probably be fine

#657
post #465

First off, there's a lot of people shooting off their mouths - ignore anyone who hasn't used ChatGPT extensively: it takes some training to learn to use it. Several senior developer friends have been using ChatGPT quite a bit and it seems to work well in lots of places: - isolated algorithms and fiddly bits - it writes complex SQL statements in seconds, for example. LLMs should makes quick work of fussy config files.…

What prompts are they finding useful for creating SQL statements?

GPT-4 is simply outstanding at writing SQL statements. I made a bunch of examples with non-trivial customer revenue metrics assessments:

https://www.dropbox.com/s/hdhycf7l00d3sx8/gpt4_attempt_sql_q...

It can do basic math reasonably well (and this is achieving generation where GPT-3 failed). Interestingly, asking it to verify itself does resolve bugs sometimes. Managed to fix subtle count() denominator bugs and an inflation-adjustment error with not much hinting on my end.

You can only see it struggle really hard at the end when it tries normalizing month ranges correctly. It seemed to reach conceptual problems over how LAST_DAY() was being used and current debug itself.

Re: Build full “product skills” and you'll probably be fine

#658

30 years ago I got tired of writing the same code over and over, so I went looking for something to cut out the repetition. Around a decade later I got tired of rewriting libraries or programs to make them exactly fit my needs. I used to really enjoy just coding for the sake of coding. But I started to value my time much more. I called this phase "losing my immortality". Any code that ChatGPT can write, I don't want…

This. It's pretty obvious that any software that can be written by machine should be. (It's almost tautological, eh?) Otherwise you're doing what David Graeber famously called "Bullshit Jobs": pointless work that only serves to establish your position in the economic structure. The immediate issues are: who decides the boundaries of (publicly) acceptable thought -and- who profits? I think you touch on the deeper and…

> It's pretty obvious that any software that can be written by machine should be.

This is such a good succinct, and I think objective, statement. It strikes me as a great lense through which to look at recent developments.

It does not imply that "all software should be written by a machine". But simply that anything that a machine can do just as well as a human, should probably be done by a machine rather than a human. And all additional value on top of that machine-produced material will continue to come from things that only humans can uniquely do well. And of course, there will continue to be many things in that latter category.

For many of us in this field, this means less busywork and more time spent working at higher levels of abstraction. More time curating, crafting, integrating, strategising. Less time working on the nuts and bolts.

And for those who love to hand-craft the nuts and bolts... I think that opportunity will still be there too. Because handcrafting will become a rarer skill, and there will still be areas where it is the correct approach.

Those of us who used to handcraft nuts and bolts but now delegate this to the machines, will still benefit from our understanding of how the nuts and bolts used to be made.

And those who grow up having never made a nut or bolt - perhaps not even knowing what nuts and bolts even are, will benefit from starting their path much earlier on in life working at a higher level of abstraction.

Re: Build full “product skills” and you'll probably be fine

#659
Had an interesting experience with OpenAI's GPT-4 while trying to solve a programming problem. It involved creating a TypeScript function that handles complex semver logic given certain conditions.

Initially, GPT-4 provided a solution that didn't work as expected. After pointing out the issue, GPT-4 attempted to fix it but still failed to resolve the problem. I decided to rewrite the function from scratch, which resulted in a cleaner and more efficient implementation.

After sharing my solution, GPT-4 provided valuable feedback on how to further optimize it. These changes made the code slightly more efficient while maintaining its clarity and functionality.

In conclusion, my experience with GPT-4 has been a mixed bag. It struggled to provide an accurate solution initially but eventually offered valuable feedback that improved my implementation.

(this was written by GPT-4 with minor modifications, I asked to summarize the conversation we had for an HN post)

Re: Build full “product skills” and you'll probably be fine

#660
post #620

Earlier quoted context omitted.

Maybe. Before Oracle (mid-80s) every company did write their own database code. I think a lot of smaller companies would struggle if that was still a requirement, but if relational/SQL had not come along we’d have something else like it.

>Before Oracle (mid-80s) every company did write their own database code. Not really. There were a ton of ISVs competing with Oracle and pretty much every mainframe and minicomputer maker also had their own database products, many of them non-SQL.

Oracle was the first commercial RDBMS (1979), with an early version of SQL. At that time every mainframe and minicomputer company offered one or more “databases,” often little more than file managers with a library of utilities. ISAM was a popular model but that describes a lot of data management systems, not a product or standard.

All commercial databases pre-Oracle were non-SQL. Watching that history get rediscovered and pushed as an improvement by people mostly too young to know better — so-called NoSQL databases — brings to mind Alan Kay’s quip about the software industry constantly reinventing the flat tire.

The hash-based Pick OS/database came out before Oracle but only ran on a few computers from Microdata and later Pr1me and Honeywell. Pick-based systems remained popular into the early 2000s in some sectors. A friend of mine still works on one, for a state government agency.

You could construct a database management system from the ISAM-based libraries for COBOL or Fortran, but I wouldn’t call those database management systems comparable to Oracle. Mostly they didn’t have a query language per se — you had to write code to get anything in or out. And they ran as part of the application process, not as a separate server dedicated to running the database engine.

Post reply on HN