Live data from Hacker News

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

twitter.com

311–320 of 829 posts

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

#311
What he says here is so true, and something I see many engineers get wrong. Don't glorify and build your career around a single language or methodology.

I believe an engineer should learn to build things in the most pragmatic way possible using the best tool for the job. This requires breadth of experience across many areas, and a focus on delivery.

The idea of "Java engineer", "Scala engineer", "Golang engineer", etc. is so absurd to me. If you want to build a long lived career that will outlast tech fashion, learn many different tools and how to build software in different ways. Be known as someone who delivers, not an expert in language x or tool y.

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

#312
post #301
post #86

Earlier quoted context omitted.

My career predates relational/SQL databases so I can confirm what you wrote. When Oracle came out the buzz was that a whole bunch of programmers would go away because managers and executives could write queries in a “natural” English-like language. That never happened. SQL is hard to master, but it’s the easy part of understanding the relational model and any particular schema. Instead Oracle and the other RDBMSs tha…

As someone trying to learn SQL it feels that there are much more steps: * language syntax * the relational model (relatively easy? It is just "there"?) * database schema, where I have 3 000 tables, or 50 0000 tables (that's how ERPs are made) * actualy knowing how to use the language * building those queries that join columns from 15 different tables together to deliver the needed data -> it sounds easy, but Im strug…

I'm not an SQL expert. But data persistency and consistency are generally very hard problems. It's a lot of steps, but I'm not sure if it more steps. More than what? If these data are stored as a big binary blob?

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

#314
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…

Yes quite agree.

The same thing applies to trying to get business people to write "executable specifications" that can be used, if not to generate the code, to at least validate that the final system does what it's supposed to.

They always complain that the "tools are too hard" but the real problem isn't the tools but that they are unable / unwilling to precisely specify what the system should do. They just want to hand wave vague phrases and have their system magically perfectly defined. It's just not going to happen.

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

#315
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…

> I'd be surprised if the next step is "Hi, I'm an ideas guy, please give me an app that does Uber, for bicycles, but better."

On an aside, this is the kind of bussiness idea a chatbot could generate now.

But I don't think it could have generated the idea for Uber when Uber* was the first...

* if you know the history of ride apps better, replace Uber with whoever was indeed first.

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

#316
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…

> Since they hire software developers to make the specification more rigid, and the managers don't seem to be getting better at this over time, why would you believe this skill set is going to go away? Some people can take a business goal and figure out how to turn it into a clear spec. Sometimes these people are programmers. However I know programmers who suck at this and I know non-programmers who don't.

This is so true! I see people in this thread talking about the contempt that "idea people" have for programmers/software engineers, but at the same time I have experienced Product Managers (the quintessential idea people?) who were really good at turning their ideas into super detailed specs.

As an aside, I'm getting a bit tired from the "programmers vs product/business people" trope. The average software engineer would be nothing without a good product manager in my experience. And going by this thread, there seems to be at least as much contempt from programmers/software engineers for product people than allegedly vice versa.

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

#317

Earlier quoted context omitted.

> So exact in fact that they will need to specify a program in a click and drag interface, or in human language. This. I started programming in Machine Code, where the "editor" was a pad of graph paper. I've watched management- and business-focused people sneer at us geeks for my entire career, and watched them drool over the thought of finally getting rid of us. Hasn't happened yet. > I'd be surprised if the next st…

re: idea people True. And once their product hits the market, if it ever gets there, they don't thrive. Prior to launch they are sooooo in love with their idea that they are meticulous about features all the while thinking they're smarter than the market. They don't understand and appreciate the value of execution. Ideas are easy. Execution - because it involves people as well as adapting to change - is 10x harder. Y…

One of the things that I'm fairly good at, is walking people from "Crazy Idea That Will Never Work," through to "Finished Product That People Want."

It tends to be a very long process, and often involves a lot of "trial balloons." I just went through that, in the last couple of years. The project we're realizing, looks absolutely nothing at all like what the CEO originally dreamed up, but everyone that has seen it, loves it.

The trick is to not start off by saying "It'll never work." That slams doors shut, right away.

It's more like, "OK, so let's walk through what we'll need to do, to make it work."

That will often result in changes being made, by the "idea person," as the plans are laid. We will also try to create test harnesses and prototypes. These often end up, with the idea person going "Hmm...it seemed like a good idea, but it doesn't work the way I wanted."

It's slow and painful, but works.

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

#318
post #301
post #86

Earlier quoted context omitted.

My career predates relational/SQL databases so I can confirm what you wrote. When Oracle came out the buzz was that a whole bunch of programmers would go away because managers and executives could write queries in a “natural” English-like language. That never happened. SQL is hard to master, but it’s the easy part of understanding the relational model and any particular schema. Instead Oracle and the other RDBMSs tha…

As someone trying to learn SQL it feels that there are much more steps: * language syntax * the relational model (relatively easy? It is just "there"?) * database schema, where I have 3 000 tables, or 50 0000 tables (that's how ERPs are made) * actualy knowing how to use the language * building those queries that join columns from 15 different tables together to deliver the needed data -> it sounds easy, but Im strug…

Shoot me an email, I’d be more than willing to pair with you. I’ve been a “software engineer” of some flavor for about twenty years now, and about five of those were spent writing SQL almost exclusively.

You can reach me at nominallyanonymous-at-protonmail-dot-com. From there I’ll give you my “durable” contact info - Slack, Discord, SMS, Signal, Telegram… whatever you use regularly, basically.

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

#320

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 highly disagree. That might (might!) be true of some segments of the tech industry, like SV-based startups, creating products no one wants.

But it's definitely not true of the average piece of software. So much of the world around us runs on software and hardware that somebody had to build. From your computer itself, to most software that people use on a day-to-day basis to do their jobs, to the cars we drive, to the control software on the elevators we ride, software is everywhere.

There is a lot of waste in software, to be sure, but I really don't think the average SE works for a company that shouldn't exist.

Post reply on HN