Hacker News Reader

> it's the incentive structure, it's the way managers and executives commonly lie or manipulate you with stories and narratives, and the politics. It's like I can see all of that in the actual code. I can see where someone stayed up way too late, or compromises were made with an overzealous executive or manager. I came into engineering because I loved to code, I stayed for the money, but when this career is long gone I'll probably still tinker with code.

As the saying goes, "I would sling code all day for free. It's the other bullshit that I need to be paid a lot for."

Management really should be thin layers in software companies. Instead, it is the only way to progress in the career ladder sometimes. Every manager in this thick layer wants to somehow show that they are doing something. They do this by creating more bureaucracy and busy work (but only for others).

Meetings actually counts as work for them. When they have a hundred meetings a week, they are happy and proud that they worked so much. For engineers/developers (or anyone producing the actual output), meetings are an imposition.

For engineers/developers (or anyone producing the actual output), meetings are an imposition.

This is true for the sort of engineers who have no input on what is being built. Once you get to the level where you're making architecture decisions you need meetings in order to discover what to build.

My advice to any developer who dislikes meetings and sees them as an imposition is to find a way to appreciate them, or stay near the bottom of the food chain.

I am not talking about discovery meetings set by engineers to discuss with other engineers. I fully realize no one is an island.

The meetings I am talking about are daily stand-ups, presentation for management (why don't you make some slides that we can present to the VP), the random late meeting set by a Product Manager because they wasted too much time on "other commitments" and could only get back to this one now.

If your discovery meetings are just engineers talking to other engineers, you're doing discovery wrong. The people building the product are *not* the only stakeholders.

I don't think you have been exposed to all kinds of software engineering.

> For engineers/developers (or anyone producing the actual output), meetings are an imposition.

> This is true for the sort of engineers who have no input on what is being built.

It's true for everyone who isn't gratuitously satisfying a desire for social dominance displays.

> Once you get to the level where you're making architecture decisions you need meetings in order to discover what to build.

Some meetings are necessary, all meetings are impositions. If you are at the level where meetings are serving your individual needs and you are calling them, you need to be very cognizant that they are still impositions, and not just for engineers. And it's good to view even your own meetings as a kind of self-imposition to be optimized and minimized in your own interest, as well as those of the other people they are imposed on.

> My advice to any developer who dislikes meetings and sees them as an imposition is to find a way to appreciate them, or stay near the bottom of the food chain.

IME, people high up in the food chain tend to also view meetings as impositions, and people who don't view meetings that way tend to get negatively noticed for it from above, below, and laterally.

Nope not at all. I am a Senior Architect, working for a high tech company, and having a formal meeting is really rare. There is almost no middle management. Team leads are trusted, are hands on, and have the full responsibility to deliver. It works extremely well and we routinely outcompete companies 10 to 100 times our size.

Let me add that I strongly encourage our competitors to have lots of meetings. With a bit of luck our competitors will have so many meetings that they will be even easier to compete with. And I also highly recommend that our competitors add more layers of middle management. For the same reason.

What's the saying? There was someone who painted the Mona Lisa and there was someone who made the McDonald's logo, but only one of them got paid. Something like that, I'm sure I'm butchering the saying. You have to make a living, but you can still code for fun. They're different types of coding.

> I've been programming since I was about nine. I still love writing software as much as I did the day that I figured out that you could compile code.

> [...]

> I came into engineering because I loved to code, I stayed for the money, but when this career is long gone I'll probably still tinker with code.

Funny, this is my exact story as well. I still remember independently re-inventing the bubble sort algorithm when I was around 10, not knowing you could do better. :)

As for the topic of "mastering software engineering," I'm not sure that's possible. The stuff we learned in school about hard algorithmic problems is not what we deal with on a daily basis; or, rather, it's not what 99% of us deal with.

What I mean is that most software engineering problems are social problems. Most software only has meaning in a social context. That is, its utility and correctness are subject to social forces [0]. This is true any time more than one person is involved in developing or using a given piece of software.

In my experience, this has been true for almost every bit of code I've ever written, the exception being some fancy numerical integration code I worked on in grad school for a bit. Even then, I could probably argue that there was a social component to it, since I was building upon the work of previous grad students.

IMO, the most important skill a software engineer can have is knowing how to identify the social forces behind the software he or she is being asked to write. You aren't paid to write code; you're paid to solve problems, and, as I said, all the real problems are social. Sometimes you can do that without code, or, at least without writing additional code, and those solutions are often the best solutions to the problem.

And, once you've written code, as you said, you're leaving behind an artifact for future software engineers to see. You're communicating with the future every time you write a line of code. Since you don't know how the future is going to interpret what you've written, you should write it as clearly as possible.

It is in this way that I believe software engineering really isn't much like engineering per se, but more like writing a book. Except that it's a book with potentially hundreds of authors.

---

[0]: If you don't believe that, then, how do you explain the existence of product managers? ;-)

Couldn’t agree more. I taught myself to program Z80 assembler when I was 11 and have been programming ever since. To solve real world problems you need to also understand the business environment you are in, the politics, the customer needs, the customer politics, the customer business model etc. “Mastering” software development is not only impossible (the field is too big) but also not enough even if you could.

> “Mastering Software Engineering" smells of professionalization. What's to master?

What’s wrong with professionalization?