Live data from Hacker News

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

news.ycombinator.com

601–610 of 733 posts

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

#601

Earlier quoted context omitted.

1000x times this. It's a weird thing our profession. There's a horrible but apt (misogynistic even) saying. Happily married men are happy husbands - Unhappily married men are great philosophers. I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that…

Why is this saying misogynistic? Because it’s a statement about men or because of the implied possibility they could be unhappy in their marriage? Also, why is it horrible? It appears this world has become manically trigger-happy to label something as -ist or -istic, when it contains even only a hint of something someone could possibly understand the wrong way. It would be curious to examine in a psychological study…

It’s only misogynistic if the husband:

1. Can only be married to a woman, sometimes a pre-arranged woman

2. Has religious or cultural norms keeping it that way

3. Improving the marriage is the woman’s territory

This is probably a realistic aphorism for a larger group of people than those who can call it misogynistic.

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

#602

Earlier quoted context omitted.

/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto. So really, you're never "doing Agile". You're "doing $X" where $X can be…

Difference between doing Agile and being agile is the same as education. You can have engineers who are educated well and you can have engineers who get stuff done, well without a high level of ‘education’.

You’re talking about training, not education. A masters in engineering will be an experience in software architecture. An engineering role under one of these management styles will be an experience in training.

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

#603

Earlier quoted context omitted.

That very well may be true, but what's wrong with trying to cheat the system and do only the fun part? Clearly some people manage to do just that. I generally don't care about making the business fly, I care about what I care about. A better discussion would be about what can you reasonably expect, for example you'll probably never lead a project which puts a limit on your salary. It may still be a good decision.

> I generally don't care about making the business fly, I care about what I care about. That's not ethical at all.

Oh no! Talk to me when the corporate structure kicks you out with zero day notice.

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

#604

Earlier quoted context omitted.

> Find a company that values programming and real productivity What's an example of a company that values "programming" over the business?

Isn't google the canonical example?

I've been a manager at Google. It is not the canonical example

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

#605
May I suggest you to take another look at refactoring? I think that if you love unit testing and debugging, you probably would love refactoring too. I like that I don't have to worry to find the perfect name for my functions and methods _on the first try_, and that I can focus in making code that works first, and after that I can worry in making clearer and more understandable.

Now, to be fair, I also like the common practices in the industry too. Scrum or kanban, ticket creation and estimation, and daily stand ups. When you're part of a team you need a lot of communication and effort to keep everybody working in the same direction. Besides, managers want to be kept informed. The how is not as important as the why.

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

#606
post #543
post #518

Earlier quoted context omitted.

Is it really that hard for owners to resist the alure of a buyout? I dunno, I always like to think that I’d continue doing the good thing that I’ve got going.

Sometimes you're kind of forced into it: if your growth starts taking off faster than you thought, you may be in need of more capital just to stay in business. At that point you have a choice: slam the brakes (turn down customers), borrow (risky), raise (dilutes you), or sell out. If you can find a solid working relationship within the acquirer's company, all is good...

There is actually nothing wrong with turning down business. No need to grow faster than you can handle. A company in the situation you describe is doing something very right, so maintaining that seems like a good strategy.

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

#609

The strangest thing is that I love refactoring, and I sort of assume that it's another one of those things that programmers love to do, but managers keep pushing us to limit our time and move on to things that are visible to customers. But now I'm wondering if that's not the case. Or maybe it's just the sort of programmer who loves abstractions and is cast as a "perfectionist". I'm currently getting my footing now as…

I love refactoring too. It kind of feels like what I imagine editing writing feels like. You've got the rough draft, but also so many lessons learned and can see the big picture now. Much easier to go back and write something cleaner after the fact. I kind of treat all of my code this way.

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

#610
As a self-taught software developer, I understand your feelings. Many tutorials, workshops, and boot camps focus on the technical aspects of software development. Coding, fixing bugs, and handling incidents are thrilling and give a sense of accomplishment.

However, when the applications I built became older, as more and more people started using them, and as the underlying tech stack continued to release new versions every year, I found myself spending more and more time patching up code to fix issues reported by users. I was patching the same code again and again or doing the exact change at ten different places and messing up in multiple ways. Since these applications were mission-critical for my clients, there was no way to avoid this.

I realized that behind-the-scenes, "boring" concepts of planning, refactoring, discussing with team members, and architecting were essential for my future as a developer. These practices allow me to spend more time on the "fun" aspects of development and less on the "boring" stuff.

It's similar to going to the gym. It may not seem important in the short term, but it's essential for a healthy long-term future.

Post reply on HN