Live data from Hacker News

Ask HN: Do you hate software engineering but love programming?

news.ycombinator.com

661–670 of 733 posts

Re: Ask HN: Do you hate software engineering but love programming?

#661
post #248

Earlier quoted context omitted.

I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one enginee…

> At large companies no one feels like they own 100% of the code, and each change is very collaborative. That's how you end up with endless process, design by committee, and having a dozen meetings with all "stakeholders" before actually writing any code. I'd much rather work at a place where individuals or small groups have a strong vision on the code and product and are capable on executing independently on that. I…

> But I understand it's a personal preference.

Indeed. No company size is perfect. There are dysfunctions typical for small companies. There are dysfunctions typical for large ones.

But people have preferences; some things they can handle, other things drive them crazy. What drives you crazy may be different from what drives your friends crazy.

Perhaps everyone should try to work once in a large corporation, and once in a startup, to figure out their own preferences.

Re: Ask HN: Do you hate software engineering but love programming?

#662
post #464

Every few months or so we get these really circle jerky posts by engineers who believe the world of business is them just pumping out code and somehow getting paid. 1) that’s the difference between a job and a hobby. You do the hard parts you’re paid to do sometimes. 2) decisions you don’t like by stakeholders you don’t like aren’t always wrong just because you see some way to “code it”. A product is not just its cod…

No one is talking about running a business. We're talking about code bureaucracy. I don't like front end, still happy to do it though, the issue is mandatory meetings, code reviews, design docs, and tests to make a simple UI change. Run a business, talk to stakeholders, make sales, but don't make programming so unpalatable that it moves at a glacial pace. Tell me what to do then let me do the thing you pay me to, and…

Code reviews should be at least a chance for other team members to learn the code - and take responsibility for it. If there's a bug they should have spotted it and the heat no longer falls entirely on you.

Tests similarly are about allowing other people to change things without fearing that they will break the code you wrote. Without them the pace of change becomes very slow or very buggy.

It's just working with other people that's more complex than working on your own.

The meetings are usually because nobody has enough information or enough authority to get things decided. We can fix that sort of thing up to a point in many ways including the agile idea of having a product owner to prevent stakeholders annoying developers.

Re: Ask HN: Do you hate software engineering but love programming?

#663

Every few months or so we get these really circle jerky posts by engineers who believe the world of business is them just pumping out code and somehow getting paid. 1) that’s the difference between a job and a hobby. You do the hard parts you’re paid to do sometimes. 2) decisions you don’t like by stakeholders you don’t like aren’t always wrong just because you see some way to “code it”. A product is not just its cod…

Totally agree. The non-fun parts are usually the parts that you have to pay someone to do. I work on a pretty complicated piece of software with some interesting technical challenges. But, the most valuable things I can work on are around collaborating with other teams, integrations, and reliability. Would much rather work on some of the unresolved technical challenges. But, that’s more hobby work, not work work.

Re: Ask HN: Do you hate software engineering but love programming?

#664
post #190

Things were better before agile / scrum / annoying processes took over. Not all companies were waterfall, they kind of just "did things" without any well defined process. This was how things were until roughly the early 2010's. I remember working for weeks, after a couple of whiteboard sessions. You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be info…

Things were better before agile / scrum moved from the developers doing it to project managers doing it.

"Project Management" and "Agile" IMO are completely opposed concepts so no wonder project managers don't get it. They still want jobs however so now presumably it's perverted agile.

Re: Ask HN: Do you hate software engineering but love programming?

#665
post #177

I (Mostly) agree with you here: > Finding and fixing bugs is a lot of fun. Incidence response is a lot of fun. Hacking on new projects is a lot of fun. Writing unit tests is fun too. I'd agree on the first three, I'm not a huge fan of unit tests though. They seem like something a "good programmer" should do but to me it's in in the CYA lane, not programming. > Refactoring, rewriting, sprint, agile, rearchitecting thi…

Unit tests allow other team members (and yourself in 6 months) to make changes with much less fear.

Sprints are supposed to be a few minutes where we spot early if someone is in trouble so we can fix it asap. The rest of the meetings should really be getting done by your product owner and maybe some kind of team lead. As you say it's usually a result of people not knowing things but sometimes that's the dev team too as in insufficiently well described requirements needing to be clarified.

Re: Ask HN: Do you hate software engineering but love programming?

#666

I co-founded a company as the only software developer and it's the most fun I've ever had building software. That includes all the refactoring, architecting and rewriting. What's important in my case is that I have awesome co-founders who have completely different roles and skills and that trust me to deliver the tech. We don't have investors, only our own money on the line. We also don't have any recurring meetings,…

If you ever do need to take on other people when you get overwhelmed then you'll end up having to develop patterns of behavior even if you don't call them processes. There might even be a point where you cannot keep up with all of it - that is a freaky feeling. Then you're trying to keep things working without being able to understand to the last detail what everyone is doing.

Your codebase might be tending towards a pile of crap or not and you'll have to try to make it not by asking people to do code reviews or tests.

Re: Ask HN: Do you hate software engineering but love programming?

#667
post #642

Earlier quoted context omitted.

Rather have a big document for a program that doesn't work?

Yes You can get there with a big document for a program that doesn't work You can't get anywhere with a program that works and no document. You might get sales, but that's someone else's job I certainly would have preferred just a big document instead of the code I was given on my current role

I meant: you'd be happy to hand your stakeholder a document about the code you would have written if you'd had time to?

Re: Ask HN: Do you hate software engineering but love programming?

#668

Earlier quoted context omitted.

Can't upvote this enough times. Time and time again you see this: people say "I hate agile because of X, Y and Z" where X, Y, and Z - at best - are orthogonal to the idea of Agile, and at worst (and perhaps even "ordinarily") are complete anathema to the spirit of Agile. Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold…

What is actually Agile then, and how does one actually practice it?

You asked about Agile, but I will talk about Scrum instead, because I am more familiar with it.

https://scrumguides.org/scrum-guide.html

Ctrl+F "JIRA" - 0 results

Ctrl+F "velocity" - 0 results

Ctrl+F "on-call" - 0 results

Ctrl+F "manager" - 0 results

Selected quotes:

> Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

> During the Sprint: No changes are made that would endanger the Sprint Goal;

> The Daily Scrum is a 15-minute event

A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.)

At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more.

At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time.

The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take.

Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.

Re: Ask HN: Do you hate software engineering but love programming?

#669
post #248

Earlier quoted context omitted.

I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one enginee…

Oh, I've definitely met princesses at large companies, though you are spot on about the ownership issues. The problem really isn't the size of the company but how siloed the code is.

Yeah, one of the 1000-person companies had a dev whole-own a critical microservice. Changing it was always a battle, because the owner was very critical of anyone touching 'his' service. Large companies aren't immune, but due to eng specs and collaboration baked into development, its less likely for this to happen.

Re: Ask HN: Do you hate software engineering but love programming?

#670
post #248

Earlier quoted context omitted.

I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one enginee…

Are you ideas normally implementable in the next month or something far-fetched? Try to come up with ideas that are low hanging fruits, easy to do but have a high value. I don't think any company/management in their right mind would constantly reject "good" ideas that ultimately result in more revenue. The ideas I see being rejected are either too far out there or some "dev utopia"-kind of ideas that don't bring in m…

The problem is there are many ways to implement a feature. Often one isn't objectively better or worse than the other (but subjectively it is).

Everyone wants the problem solved, but how the problem is solved leads to frustration.

Post reply on HN