6 ms·

I call myself a programmer to avoid people thinking I want to be a manager or spend my days in meetings. I want people to expect 90% of my output to be code. I

by elif 7y ago

I call myself a programmer to avoid people thinking I want to be a manager or spend my days in meetings. I want people to expect 90% of my output to be code. If this is good for a career? Don't know don't care. It's what I do and enjoy, and there are many slippery slopes to not coding and becoming rusty, and ending up on the M train by default.

scarface74 7y ago
How do you know what to code or whether you should even be coding at all if you aren’t willing to spend the time knowing the business and the customers?
- elif 7y ago
  Because there are hard problems to solve. I'm into computer science not capitalism.
  - scarface74 7y ago
    I bet the company you work for is “into capitalism”.
    - elif 7y ago
      You don't know anything about my particular situation, and happen to be very wrong. But assuming the role of your rhetorical me, there are thousands more companies just like "mine". they all provide paychecks.
      - scarface74 7y ago
        And how do those companies earn money to give you a paycheck?
        elif 7y ago
        Most of these paychecks come from unprofitable companies. I'm not sure what point you are wanting me to walk into. Are we still talking about programmer management strategy?
        scarface74 7y ago
        And whether they are “unprofitable” or not doesn’t mean they don’t either seek to become profitable or get bought out - ie your livelihood is still based on capitalism.
  - comicjk 7y ago
    Pet peeve of mine: solving practical problems often involves capitalism in our system, but that doesn't mean practicality is capitalism. If you're writing ad code, you're working on capitalism only. If you're writing railway logistics code, you're doing practical work that any society needs, capitalist or not. And yes, this might involve understanding customers (or as a different system might call them, "people"). The important question would be "is this work useful," not "does this work involve capitalism."
    - scarface74 7y ago
      Speaking of railway logistics. Railroad car repair billing is esoteric and complicated. I wrote software dealing with this at one job. https://www.railinc.com/rportal/documents/18/260737/CRB_ProceduresManual.pdf https://www.railinc.com/rportal/documents/18/260737/CRB_Proc...
  - lexicality 7y ago
    Do you not consider finding out what the person asking for things actually wants to be a hard problem to solve? I live to build things and continuously fend off attempts to slide me into management, but I find actually programming things to be only half the part of the puzzle. Humans are extremely bad at articulating what they want and will generally tell you the wrong thing up front because they haven't thought it through fully. A day spent with a stakeholder carefully picking their brains and properly crafting a plan can be just as satisfying as a day of straight coding - sometimes more so. (tbh this is probably also why I find UX work so interesting - getting a user to click on a button is considerably harder than making the button in the first place)
- matz1 7y ago
  In the case of me >How do you know what to code Someone need something to be made or done, I help them by writing code. >whether you should even be coding I've been doing it for long time >if you aren’t willing to spend the time knowing the business and the customers? That's precisely the reason I prefer code. I'm not that interested or even willing to spend time knowing the business and the customers.
  - thestepafter 7y ago
    I would argue that knowing the business and the customers makes you a much better programmer though. I would rather a programmer spend 75% of their time programming and 25% seeking to understand why they are programming instead of 90%+ heads down with little thought or attention to why they are programming.
- vlunkr 7y ago
  This shouldn’t be a problem in a business with well defined roles. Boss/manager says customer wants x. I don’t care why they want that, and I may even think it’s dumb, but I can make it happen. After all, I get paid to solve problems with code, not interpret customer requests.
  - scarface74 7y ago
    I was once interviewing for a job as a senior engineer/lead role. The CTO - my eventual manager - was asking me a lot of high level technical questions even though he was a very competent developer. Then, another developer who had been there for a decade asked me how I would go about writing “address validation routines” - It was a real world problem he was facing. I told him that I wouldn’t. That’s not the vertical the business was in. The best code is the code that you don’t have to write. Address validation software is a solved problem and there are plenty of third party CASS solutions and yes they cost money but being able to write address validation software is not the company’s competitive advantage or its differentiator in the market. It’s better to outsource it. That’s one less thing we would have to maintain and debug. The developer wasn’t impressed. The CTO was. I’ve spent my entire career asking questions and making sure we were building the right things. My first job out of college over 20 years ago I was the sole developer on a project to write a data entry system that was used by a new department with a dozen new employees. I had to actually talk to our potential client to gather specs myself.
    - vlunkr 7y ago
      > I’ve spent my entire career asking questions and making sure we were building the right things. But this gets back to what OP was saying. Spending time asking questions == spending time in meetings. Not writing code. I’m not advocating for never asking questions or suggesting better ways, just saying that I prefer to work where someone else handles the bulk of that so I can focus on what I specialize in.
  - magicalhippo 7y ago
    > After all, I get paid to solve problems with code, not interpret customer requests. But how to know what to solve... At least for my job, interpreting customer requests is key. The customer knows what they want, but they don't always realize what they want is not the best solution. Often I can steer the customer to a vastly superior solution to what they initially had in mind. Not seldom this superior solution can re-use existing code, sometimes entirely.
SkyPuncher 7y ago
I think this post had tons of good advice, but I feel like programmer vs engineer is a micro-optimization. There's no standard terminology and nearly every company has a slightly different definition of terms.
freehunter 7y ago
I’ve met many programmers/engineers who are terrified of becoming management and make (what I believe to be) poor career choices trying to avoid it. Instead they get passed over for pay raises and interesting opportunities because they’re seen as being difficult to work with. When times get lean, I’ve seen those people get laid off first because no one likes working with them. I work on a team of 50 employees. For those 50 people, there are two managers. 1 out of 25 isn’t great odds of being accidentally promoted into management without your consent. Your working style may be right for you, I’m not questioning that. But in a thread targeted at career advice for junior engineers, I thought it’d chime in from the other side. The chances of accidentally ending up as a manager are very slim. Don’t destroy your career and miss out on interesting opportunities to avoid something that’s not likely in the first place.
- deleted 7y ago
  [deleted]
- SomeOldThrow 7y ago
  If only we could retroactively demote all the managers who suck at it!
  - linuxftw 7y ago
    If you're at a healthy organization, they support managers transitioning back into engineering.
- whycombagator 7y ago
  > I work on a team of 50 employees. For those 50 people, there are two managers. 1 out of 25 isn’t great odds of being accidentally promoted into management without your consent. Where I work it's about 8/50. But I don't have to worry about being a manager - because they only get hired from outside.
twblalock 7y ago
The author's point is that your job is not to produce code, but rather to produce good business outcomes. Obviously you do that by producing code (and participating in design meetings and collaborating with other parts of the company in various ways). Firefighters don't call themselves ladder and hose operators. Those are just the tools they use. Their job is to fight fires so they call themselves firefighters.

by elif 7y ago

scarface74 7y ago

How do you know what to code or whether you should even be coding at all if you aren’t willing to spend the time knowing the business and the customers?

elif 7y ago
Because there are hard problems to solve. I'm into computer science not capitalism.
- scarface74 7y ago
  I bet the company you work for is “into capitalism”.
  - elif 7y ago
    You don't know anything about my particular situation, and happen to be very wrong. But assuming the role of your rhetorical me, there are thousands more companies just like "mine". they all provide paychecks.
    - scarface74 7y ago
      And how do those companies earn money to give you a paycheck?
      - elif 7y ago
        Most of these paychecks come from unprofitable companies. I'm not sure what point you are wanting me to walk into. Are we still talking about programmer management strategy?
        scarface74 7y ago
        And whether they are “unprofitable” or not doesn’t mean they don’t either seek to become profitable or get bought out - ie your livelihood is still based on capitalism.
- comicjk 7y ago
  Pet peeve of mine: solving practical problems often involves capitalism in our system, but that doesn't mean practicality is capitalism. If you're writing ad code, you're working on capitalism only. If you're writing railway logistics code, you're doing practical work that any society needs, capitalist or not. And yes, this might involve understanding customers (or as a different system might call them, "people"). The important question would be "is this work useful," not "does this work involve capitalism."
  - scarface74 7y ago
    Speaking of railway logistics. Railroad car repair billing is esoteric and complicated. I wrote software dealing with this at one job. https://www.railinc.com/rportal/documents/18/260737/CRB_ProceduresManual.pdf https://www.railinc.com/rportal/documents/18/260737/CRB_Proc...
- lexicality 7y ago
  Do you not consider finding out what the person asking for things actually wants to be a hard problem to solve? I live to build things and continuously fend off attempts to slide me into management, but I find actually programming things to be only half the part of the puzzle. Humans are extremely bad at articulating what they want and will generally tell you the wrong thing up front because they haven't thought it through fully. A day spent with a stakeholder carefully picking their brains and properly crafting a plan can be just as satisfying as a day of straight coding - sometimes more so. (tbh this is probably also why I find UX work so interesting - getting a user to click on a button is considerably harder than making the button in the first place)
matz1 7y ago
In the case of me >How do you know what to code Someone need something to be made or done, I help them by writing code. >whether you should even be coding I've been doing it for long time >if you aren’t willing to spend the time knowing the business and the customers? That's precisely the reason I prefer code. I'm not that interested or even willing to spend time knowing the business and the customers.
- thestepafter 7y ago
  I would argue that knowing the business and the customers makes you a much better programmer though. I would rather a programmer spend 75% of their time programming and 25% seeking to understand why they are programming instead of 90%+ heads down with little thought or attention to why they are programming.
vlunkr 7y ago
This shouldn’t be a problem in a business with well defined roles. Boss/manager says customer wants x. I don’t care why they want that, and I may even think it’s dumb, but I can make it happen. After all, I get paid to solve problems with code, not interpret customer requests.
- scarface74 7y ago
  I was once interviewing for a job as a senior engineer/lead role. The CTO - my eventual manager - was asking me a lot of high level technical questions even though he was a very competent developer. Then, another developer who had been there for a decade asked me how I would go about writing “address validation routines” - It was a real world problem he was facing. I told him that I wouldn’t. That’s not the vertical the business was in. The best code is the code that you don’t have to write. Address validation software is a solved problem and there are plenty of third party CASS solutions and yes they cost money but being able to write address validation software is not the company’s competitive advantage or its differentiator in the market. It’s better to outsource it. That’s one less thing we would have to maintain and debug. The developer wasn’t impressed. The CTO was. I’ve spent my entire career asking questions and making sure we were building the right things. My first job out of college over 20 years ago I was the sole developer on a project to write a data entry system that was used by a new department with a dozen new employees. I had to actually talk to our potential client to gather specs myself.
  - vlunkr 7y ago
    > I’ve spent my entire career asking questions and making sure we were building the right things. But this gets back to what OP was saying. Spending time asking questions == spending time in meetings. Not writing code. I’m not advocating for never asking questions or suggesting better ways, just saying that I prefer to work where someone else handles the bulk of that so I can focus on what I specialize in.
- magicalhippo 7y ago
  > After all, I get paid to solve problems with code, not interpret customer requests. But how to know what to solve... At least for my job, interpreting customer requests is key. The customer knows what they want, but they don't always realize what they want is not the best solution. Often I can steer the customer to a vastly superior solution to what they initially had in mind. Not seldom this superior solution can re-use existing code, sometimes entirely.

SkyPuncher 7y ago

I think this post had tons of good advice, but I feel like programmer vs engineer is a micro-optimization. There's no standard terminology and nearly every company has a slightly different definition of terms.

freehunter 7y ago

I’ve met many programmers/engineers who are terrified of becoming management and make (what I believe to be) poor career choices trying to avoid it. Instead they get passed over for pay raises and interesting opportunities because they’re seen as being difficult to work with. When times get lean, I’ve seen those people get laid off first because no one likes working with them. I work on a team of 50 employees. For those 50 people, there are two managers. 1 out of 25 isn’t great odds of being accidentally promoted into management without your consent. Your working style may be right for you, I’m not questioning that. But in a thread targeted at career advice for junior engineers, I thought it’d chime in from the other side. The chances of accidentally ending up as a manager are very slim. Don’t destroy your career and miss out on interesting opportunities to avoid something that’s not likely in the first place.

deleted 7y ago
[deleted]
SomeOldThrow 7y ago
If only we could retroactively demote all the managers who suck at it!
- linuxftw 7y ago
  If you're at a healthy organization, they support managers transitioning back into engineering.
whycombagator 7y ago
> I work on a team of 50 employees. For those 50 people, there are two managers. 1 out of 25 isn’t great odds of being accidentally promoted into management without your consent. Where I work it's about 8/50. But I don't have to worry about being a manager - because they only get hired from outside.

twblalock 7y ago

The author's point is that your job is not to produce code, but rather to produce good business outcomes. Obviously you do that by producing code (and participating in design meetings and collaborating with other parts of the company in various ways). Firefighters don't call themselves ladder and hose operators. Those are just the tools they use. Their job is to fight fires so they call themselves firefighters.