Live data from Hacker News

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

news.ycombinator.com

391–400 of 733 posts

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

#391

Earlier quoted context omitted.

Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, prototyping and then making a more informed decision is my goto approach, instead of planning forever. Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things th…

> It's a reason waterfall was abandoned. Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks. But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, h…

Exactly this. Agile is often seen as an excuse to throw out any sort of design. You wind up with fixing the mess made last sprint in the next. But, good news, there are Jira tickets with points assigned for the half-baked fixes!

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

#392

Earlier quoted context omitted.

Agile is made up. The vast majority of places “do it wrong”. Coaches come in and make things even worse, with even less understanding. Saying “they are doing it wrong” and having nothing change isn’t doing anything, and it’s not really a great point. (Not specifically calling you out I just hear this all the time) “Fauxagile” *is* agile, because thats what the majority of places in reality do. “Agile” needs a complet…

Productive teams understand that any "way of working" is just a means to an end, and that good teams find a way to work that suits them (and their situation).

"Individuals and interactions over processes and tools" as the Agile Manifesto would call it. Quite different from having a certified scrum master

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

#393
I wouldn't place all the blame on sprints, fauxagile, etc.

The industry is driven by fashion and medium.com-led development.

If you're not jumping on the in-vogue band-wagon then you'll be punished.

After a while you've seen it again and again and you want to avoid it. But that puts you at odds with the industry and employers.

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

#394

I am the exact opposite. I mean, I don’t like processes and meetings, but I do like the planning and architecture part much more than I like actually writing code. Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved. I’ve never understood p…

Would it help if, as someone on the other side that for the most part only plans as the feature is discussed on their head and then jumps into code, I say that the code is where I "document" my plans as types, comments, tests, and stubs, which I progressively expand into implementations? On the same vein, I'd add that some languages greatly facilitate this process, while others make it more of a pain.

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

#396

I am the exact opposite. I mean, I don’t like processes and meetings, but I do like the planning and architecture part much more than I like actually writing code. Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved. I’ve never understood p…

I am stunned by how close this description aligns with my thinking. I think that reading and prior consideration are fast fading in this industry for the reason you put so well, "everyone is used to learning by doing."

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

#397
post #301

Earlier quoted context omitted.

That's fine until half or more of the team moves on, then you have a spaghetti mess that newcomers have to theorize about and clean up.

I'm talking about product design, not technical design. But I don't think specifications help in the long term there, either. I think the way you get designs that are understood by both old-timers and newcomers is continuous improvement of the code through refactoring and cleanup.

> I'm talking about product design, not technical design.

Even worse!

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

#398

Earlier quoted context omitted.

Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, prototyping and then making a more informed decision is my goto approach, instead of planning forever. Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things th…

> It's a reason waterfall was abandoned. Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks. But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, h…

> Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is.

Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done.

Waterfall never existed as some kind of formal process. It was invented as an illustrative device.

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

#399
> I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get out.

If you haven't read it, I highly recommend A Philosophy of Software Design by John Ousterhout. His talk is a great teaser for the book: https://www.youtube.com/watch?v=bmSAYlu0NcY

Here's the thing: a program properly written for the future does not take longer to get out. Not much, at least. What we instinctively think of as "future proof" is generally anything but: by anticipating some particular kind of change that may happen some time in the future, but in practice almost never does, we end up with more complex programs that are harder to modify when an actual (typically unforeseen) change comes our way.

The best way to future proof your program is to make it simpler, according to the requirement you are currently aware of. If you expect a particular change, sure, plan for it. But for the unexpected, just keep it simple. Because simple is easier to adapt, add to, or rewrite.

That said, the simplest solution is rarely the most obvious. Making thing simple does take a bit more time than rushing through the first thing that comes to mind. But it also pays off in a matter of weeks, so it's quite worth it.

And if you have a hard time assessing what "simple" means, SLoC is a surprisingly good metric (we have research that shows this). And mostly your modules should be deep: small APIs that hide significant implementations. I think of it as encapsulation on steroids.

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

#400
post #303

Earlier quoted context omitted.

I read something about how a lot of 'super group' bands kind of don't do anything truly great because of this type of dynamic. They all know they're good, they know the others are good, and they all have a bit of an ego and don't want to stomp on the others, so they all tend to "go along with it" without getting too pushy. That leads to good, but not great music.

Enterprise software is not art and shouldn't be approached the same way. You want a roller-coaster-like experience, go join a startup

No one said 'roller coaster'. Part of quality software is saying 'no' to stuff, or having a coherent vision, not 'software by committee'.
Post reply on HN