5 ms·

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. Corporate c

by kodah 5y ago

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. Corporate code gives me the kind of feels that I see in other comments here about burnout. I often tell folks that when I go to work I am a shell of the man I really am, git clone --depth 1 if you will. It isn't necessarily the code itself that bothers me; 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. "Mastering Software Engineering" smells of professionalization. What's to master? Algorithms, data structures, patterns? To me, the mastery of software engineering is learning to learn and identifying what things to learn when. There will be a thing after coding, and the same kind of people will inhabit that job, I suspect.

wheelinsupial 5y ago
> “Mastering Software Engineering" smells of professionalization. What's to master? What’s wrong with professionalization?
nine_zeros 5y ago
> 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.
- onion2k 5y ago
  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.
  - mbrodersen 5y ago
    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.
    - mbrodersen 5y ago
      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.
  - nine_zeros 5y ago
    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.
    - coldacid 5y ago
      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.
actually_a_dog 5y ago
> 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? ;-)
- mbrodersen 5y ago
  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.

by kodah 5y ago

wheelinsupial 5y ago

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

nine_zeros 5y ago

> 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.

onion2k 5y ago
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.
- mbrodersen 5y ago
  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.
  - mbrodersen 5y ago
    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.
- nine_zeros 5y ago
  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.
  - coldacid 5y ago
    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.

actually_a_dog 5y ago

> 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? ;-)

mbrodersen 5y ago
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.