4 ms·

>>>> In fact, I would argue that we are paid comparatively more than other careers because to be successful in our work we must take the confused requests or re

>>>> In fact, I would argue that we are paid comparatively more than other careers because to be successful in our work we must take the confused requests or requirements we are given and make sense of them, make them fit into the actual business need, and then execute on that improved understanding. It works both ways. From the "other side," communicating requirements to programmers is also hard. The problem is compounded if the requirements involve specialized domain knowledge, including math. And everybody thinks they have the best understanding of business needs. Everybody thinks the "other side" is the problem. There may be conflicting expectations. For instance, when I communicate requirements, I actually try not to precisely specify every detail. I want the programmers to come up with their own ideas and solutions. I think the high pay is just a supply/demand issue. Paradoxically, most of us who program think it's easy, but most people who try to learn how to program find it to be prohibitively difficult. And we don't know why. Also, demand fuels itself in peculiar ways: The visibility and aesthetic appeal of software make it a focal point of the business. Investors are gaa-gaa over it. When the big-wigs review a business unit, they will ask: "What is your digital strategy?" It's hard for an electrical engineer to make their work self-advertising in this way. Second, Brooks' Law suggests that there may be positive feedback cycles in the need for programmers within organizations with large ongoing development efforts. Hiring more programmers makes programming harder. On the other hand, my general advice to all workers is to plan for lower pay. My spouse and I have done this throughout our careers, and I don't regret it an any way. For instance we bought half the house that the bank said we could "afford."

z9znz 4y ago
I'm sorry to be meta, but geez. You make some reasonable points, and while some of your opinions differ from mine, I think they are valid for your experiences. And yet, you had been downvoted. (I tried to help you back up :) ). And now because of that meta stuff, I'll take the time to reply. I already talk too much, so I had skipped this one. But now I must. > communicating requirements to programmers is also hard I absolutely agree. I also wonder: in business school, or management school, do they have classes to teach people how to break down their needs and articulate them to developers? For example, if you want a house built you will talk to an architect who will make a plan, and those plans will be uniform to some standards. The plans will be consumed by some building contractor, and that person will arrange a lot of actual physical work. But in the business world, there is rarely such formality. Probably in high risk domains like air travel and such there certainly is, but in the typical companies it's just some executive or marketer with an idea telling the CIO what is desired, and the CIO passes the concept to the product team. From the dozen or so companies I have worked with or for, I have not seen consistent approaches to this idea->project communication process. And in my case, I have also done several projects, sometimes long term gigs, for small businesses where I will be working directly with the owner. The owners I worked with knew their business domain very well, but they knew very little about software or technology. Success meant me listening to their initial request and then asking a lot of broader questions to ascertain the actual need. For me it's quite fun, because I get to learn about their real problems, and then I can deliver a great solution which makes their lives better. > most of us who program think it's easy, but most people who try to learn how to program find it to be prohibitively difficult I do believe programming is easy, at least in terms of turning a specific need into code. For example, if you have a CSV file that you need ingested into your database, and you know the meaning of each column in the CSV, then it is just a matter of cleaning up the data and type converting it (and having a plan for how to handle fields which cannot be cleaned or are empty). What is NOT easy is taking a big vague idea and programming against it. This I have encountered many times with non-technical people. They just want a "simple" X. So I start asking them questions, and inevitably we reach conditions which could exist but which they don't know how to handle. I politely say, "We have to know what to do when Y occurs, even if we just tell the user to go away." Also, to be fair, big ideas are hard to program because they are logistical or organizational problems. They are not programming problems though. > visibility and aesthetic appeal This is definitely true. People are more motivated (and more willing to pay money) for stuff they can see. However, there are a lot of IT divisions at companies where the IT group is only a cost center. They enable all the other workers, but they are treated as unfortunate costs, like barnacles on a ship. Chances are they are paid much lower than SWEs in companies where software is a first class product. > plan for lower pay Another common version of this is "live below your means". I think most of us have fallen for the opposite. In my early years, I was a moron with money because I knew that every job change meant a 20-50% salary increase. And that was true for several iterations! Then it was no longer true, but I had lived as if my salary was large all the way. It was stupid, and I eventually learned. I think a better approach to living and finances is to budget (rule #1, and it implies tracking expenses and patterns of expenditures) and save so you can weather career/health/financial storms with less stress. Wha† is most perhaps surprising to me is that the biggest driver to me reducing spending is overaccumulation of stuff. Properly getting rid of stuff is a job. Sure we can throw it away or drop it off at Goodwill, but often it will just end up in a landfill. Given the current ecological state we are in, that is practically criminal.

z9znz 4y ago

I'm sorry to be meta, but geez. You make some reasonable points, and while some of your opinions differ from mine, I think they are valid for your experiences. And yet, you had been downvoted. (I tried to help you back up :) ). And now because of that meta stuff, I'll take the time to reply. I already talk too much, so I had skipped this one. But now I must. > communicating requirements to programmers is also hard I absolutely agree. I also wonder: in business school, or management school, do they have classes to teach people how to break down their needs and articulate them to developers? For example, if you want a house built you will talk to an architect who will make a plan, and those plans will be uniform to some standards. The plans will be consumed by some building contractor, and that person will arrange a lot of actual physical work. But in the business world, there is rarely such formality. Probably in high risk domains like air travel and such there certainly is, but in the typical companies it's just some executive or marketer with an idea telling the CIO what is desired, and the CIO passes the concept to the product team. From the dozen or so companies I have worked with or for, I have not seen consistent approaches to this idea->project communication process. And in my case, I have also done several projects, sometimes long term gigs, for small businesses where I will be working directly with the owner. The owners I worked with knew their business domain very well, but they knew very little about software or technology. Success meant me listening to their initial request and then asking a lot of broader questions to ascertain the actual need. For me it's quite fun, because I get to learn about their real problems, and then I can deliver a great solution which makes their lives better. > most of us who program think it's easy, but most people who try to learn how to program find it to be prohibitively difficult I do believe programming is easy, at least in terms of turning a specific need into code. For example, if you have a CSV file that you need ingested into your database, and you know the meaning of each column in the CSV, then it is just a matter of cleaning up the data and type converting it (and having a plan for how to handle fields which cannot be cleaned or are empty). What is NOT easy is taking a big vague idea and programming against it. This I have encountered many times with non-technical people. They just want a "simple" X. So I start asking them questions, and inevitably we reach conditions which could exist but which they don't know how to handle. I politely say, "We have to know what to do when Y occurs, even if we just tell the user to go away." Also, to be fair, big ideas are hard to program because they are logistical or organizational problems. They are not programming problems though. > visibility and aesthetic appeal This is definitely true. People are more motivated (and more willing to pay money) for stuff they can see. However, there are a lot of IT divisions at companies where the IT group is only a cost center. They enable all the other workers, but they are treated as unfortunate costs, like barnacles on a ship. Chances are they are paid much lower than SWEs in companies where software is a first class product. > plan for lower pay Another common version of this is "live below your means". I think most of us have fallen for the opposite. In my early years, I was a moron with money because I knew that every job change meant a 20-50% salary increase. And that was true for several iterations! Then it was no longer true, but I had lived as if my salary was large all the way. It was stupid, and I eventually learned. I think a better approach to living and finances is to budget (rule #1, and it implies tracking expenses and patterns of expenditures) and save so you can weather career/health/financial storms with less stress. Wha† is most perhaps surprising to me is that the biggest driver to me reducing spending is overaccumulation of stuff. Properly getting rid of stuff is a job. Sure we can throw it away or drop it off at Goodwill, but often it will just end up in a landfill. Given the current ecological state we are in, that is practically criminal.