Doing too much work on one's own before looping in others • Hacker News Board

Re: Doing too much work on one's own before looping in others

#391

Post by smugglerFlynn » Fri, Jan 28, 2022, 12:53 PM UTC

babycake wrote: post #104

To be honest, I don't think this is any of the engineer's fault. I think we're an open creature by nature; we like to share and explore ideas with others. In the corporate field, what I've observed is that deliveries are most important. Not just any deliveries, but the project has to be big and "impactful" (as in, other teams use it too), and you personally have to own it. Like your name has to be attached to it. No…

What you are describing is mostly related to practice of building organizational units focused purely on implementation, and nothing else. Your personal success in such a unit depends heavily on a number of successful implementations under your belt.

The more organization separates project implementation from the goal-setting and strategic work, the less reasons are there for people responsible for implementation to focus on something different than just getting another green checkmark on that project milestone (and getting recognized as the one who was most impactful in getting there).

Sustainability, recognition of actual business value, meaningful team work — all of these quickly go out the window as people focus on gaming the only metric they’ve been assigned.

Re: Doing too much work on one's own before looping in others

#392

Post by marcus_holmes » Fri, Jan 28, 2022, 4:24 PM UTC

MonaroVXR wrote: post #387

marcus_holmes wrote: post #332

Earlier quoted context omitted.

I hate being treated as "just the nerd who pushes the nerd-buttons to make the thing we want work", as if the important part of the work was having the idea and not the execution. One reason they do this is usually around control. A lot of people feel like they have to be in control of everything in order to be safe. There may be ways you can make them feel safe without needing them to be in control. Another reason i…

> "building a sales/marketing channel doesn't actually need a product at the start..." Never knew this, can you tell more about it?

The technique of building the funnel to point to a "sign up for our mailing list and we'll let you know when the product is ready!" link. You get valuable customer insight from the funnel, and if your marketing funnel is working right then you'll get interested customers in your mailing list. If it's not then you can iterate on it, and find something that works (or fail fast if you can't find anything that works).

Re: Doing too much work on one's own before looping in others

#393

Post by mikeshi42 » Sat, Jan 29, 2022, 8:18 AM UTC

marcus_holmes wrote: post #392

MonaroVXR wrote: post #387

Earlier quoted context omitted.

> "building a sales/marketing channel doesn't actually need a product at the start..." Never knew this, can you tell more about it?

The technique of building the funnel to point to a "sign up for our mailing list and we'll let you know when the product is ready!" link. You get valuable customer insight from the funnel, and if your marketing funnel is working right then you'll get interested customers in your mailing list. If it's not then you can iterate on it, and find something that works (or fail fast if you can't find anything that works).

I'm curious if you still see this working well these days, or what techniques you use to make it work well. I've historically found those types of pages quite useless when we're in a time that anyone can throw up a page to try to validate vaporware and no one wants to give out emails.

I have a feeling that advice was great 10 years ago, and not so great now.

Re: Doing too much work on one's own before looping in others

#394

Post by spmurrayzzz » Tue, Feb 01, 2022, 5:55 PM UTC

ziggus wrote: post #385

spmurrayzzz wrote: post #16

Earlier quoted context omitted.

I'm curious, what about that semantic differentiation is confusing for you? At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".

Maybe in your experience that conflation makes sense, but a developer is not necessarily a software engineer. There are distinct educational programs that differ between "computer science" and "software engineering", and a number of professional organizations are lobbying for software engineering licensure, similar to other engineering professions. Even Dijkstra knew of the differentation: '"A number of these phenome…

I'm glad you brought up Dijkstra. He's famous (amongst many other things) for coining the phrase/concept "separation of concerns". He considered this to be a fundamental principle in software engineering, giving the field of programming more structure as you allude to in your comment.

But that SoC concept is fairly endemic in a field of folks who self-identify as "developers". The MVC/MVVM craze of the late 2000s and early 2010s had this plastered on every blog. You can call the self-identification mismatch a taxonomy issue, but my original comment is trying to deduce why that distinction matters at all in practice if developers are embracing concepts that we would consider "proper" software engineering.

I suspect the distinction is just noise at this point.

Re: Doing too much work on one's own before looping in others

#395

Post by theflashjames » Sat, Feb 05, 2022, 4:40 PM UTC

drawkbox wrote: post #145

Trasmatta wrote: post #53

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset i…

This post has so much insight in it, that I felt empowered when I read it.