Do call yourself a programmer, and other career advice(yosefk.com)
yosefk.com
Do call yourself a programmer, and other career advice
http://www.yosefk.com/blog/do-call-yourself-a-programmer-and-other-career-advice.html
18 comments
I totally agree.
If I'm hiring someone for my team, I need to see skill. Or smarts.
If we're hiring an outside consultant, it's always for technical knowledge that we don't have. Again we need to see skill.
If we need to hire another team lead, it's usually because we have no one to promote from within (either due to experience or lack of volunteers), and again we need to see skill.
I don't hire for marketing, but I'd hope that they also want to see results and could care less if you've programmed before. Indeed it's likely irrelevant.
If I'm hiring someone for my team, I need to see skill. Or smarts.
If we're hiring an outside consultant, it's always for technical knowledge that we don't have. Again we need to see skill.
If we need to hire another team lead, it's usually because we have no one to promote from within (either due to experience or lack of volunteers), and again we need to see skill.
I don't hire for marketing, but I'd hope that they also want to see results and could care less if you've programmed before. Indeed it's likely irrelevant.
something to consider, though: your job may not be the best opportunity for this hypothetical candidate we're musing about. for pure programming skill, there is no well-defined "value" for the business, which means you simply want to hire the best programmer for the least cost. in many markets today this is about $200k for an entry level programmer (employer costs). why pay more than that?
the point of marketing mumbo-jumbo is that it frames the value of the individual. if a candidate is capable of making you $10 million extra dollars, why not pay them $1m? you'd be a fool not to!
the point of marketing mumbo-jumbo is that it frames the value of the individual. if a candidate is capable of making you $10 million extra dollars, why not pay them $1m? you'd be a fool not to!
Erm... because that $10M is a conjecture, while the $1M is a cost paid upfront with complete certainty? Or do you want to pay in equity? Also - because someone else is willing to do the same job for less? I'm not sure that "framing my value" will help me when someone is willing to do the same for less money.
In Georgia, it is the mostly used title - "Programisti".
Because, we don't have one single word, the synonym of "Software". So word by word translation of "Software Engineer" in Georgian would be:
Computer Program Provisioning Engineer.
Nobody uses this title.
Because, we don't have one single word, the synonym of "Software". So word by word translation of "Software Engineer" in Georgian would be:
Computer Program Provisioning Engineer.
Nobody uses this title.
When I was first started out in programming, someone gave me the advice "never work at a company where you're a cost, always work at a company where your output is [directly tied to] the profit."
It seemed like a truism, and was somewhat memorable. To date, the only really bad jobs I've had in programming/engineering/what have you were ones where my work output was seen as a cost and not as a product or service, so anecdotally it's worked out.
It seemed like a truism, and was somewhat memorable. To date, the only really bad jobs I've had in programming/engineering/what have you were ones where my work output was seen as a cost and not as a product or service, so anecdotally it's worked out.
I am suprised the author does not mention growing a beard and wearing sandals among his career advice. That sure has kept me from having to interact with the likes of Patrick McKenzie.
First of all, taking patio11 too seriously is a sing of having inadequate mental representation of so-called reality.
Ironically, there is some unintentional truth is his blogpost - one really shouldn't call oneself programmer, because what he described is a dumb coder. Programmer could realize what is blogging, not vise versa.)
A programmer (one who understands how things works and why) will easily avoid such scenarios like ending up in a coding sweatshop or toxic things like PHP, Java or JavaScript. It is obvious that one should avoid certain things, like one avoids scams, frauds or just wrong things.
Real programmers, such as rtm, pg (god forbid!) sysoev would always find a niche for oneself and a project to do. The difference is that they themselves would choose what to program and why, not someone else.
Another point is about whose opinion one should value and why. Programmers usually does not care what "talking-heads" are broadcasting, intuitively and correctly anticipate that there would be zero useful or even interesting information for them. It is like to read, say, Oracle's press-releases and PR pamphlets about mysql instead of actual Changelog files.
So, right, do not call yourself programmer if you're mere a coder or blogger. There is some truth in it.)
Ironically, there is some unintentional truth is his blogpost - one really shouldn't call oneself programmer, because what he described is a dumb coder. Programmer could realize what is blogging, not vise versa.)
A programmer (one who understands how things works and why) will easily avoid such scenarios like ending up in a coding sweatshop or toxic things like PHP, Java or JavaScript. It is obvious that one should avoid certain things, like one avoids scams, frauds or just wrong things.
Real programmers, such as rtm, pg (god forbid!) sysoev would always find a niche for oneself and a project to do. The difference is that they themselves would choose what to program and why, not someone else.
Another point is about whose opinion one should value and why. Programmers usually does not care what "talking-heads" are broadcasting, intuitively and correctly anticipate that there would be zero useful or even interesting information for them. It is like to read, say, Oracle's press-releases and PR pamphlets about mysql instead of actual Changelog files.
So, right, do not call yourself programmer if you're mere a coder or blogger. There is some truth in it.)
You know, somehow your comment conveys a uniquely Russian atmosphere, making me feel slightly nostalgic.
You should call yourself whatever based on the situation.
If you are hanging out with a group of consultants, you call yourself consultant; if you are a special effects programmer, and talking to a model, you say you're in the movie business; if you are interviewing with the author, you call yourself programmer.
The best way to connect with others is to understand how they perceive things and find ways to relate to them, not enforcing your own world view onto them.
If you are hanging out with a group of consultants, you call yourself consultant; if you are a special effects programmer, and talking to a model, you say you're in the movie business; if you are interviewing with the author, you call yourself programmer.
The best way to connect with others is to understand how they perceive things and find ways to relate to them, not enforcing your own world view onto them.
This so obvious I'm amazed that it isn't discussed every time this topic comes up. Programmers seem to think that there is something "dirty" about adjusting your language according to audience.
> Programmers seem to think that there is something "dirty" about adjusting your language according to audience.
Yes. I am struggling with this right now, myself. I mean, not specifically that, but this general idea that putting effort into social bullshit that has little to do with my actual competence is dirty. It really /does/ feel dirty, and I have a difficult time articulating why.
The problem is that I have moved myself more towards management, and so getting people to do what I want really is part of 'competence' now.
A big part of this is that humility (false or not) is so absolutely core to getting along with other engineers, and so absolutely terrible when dealing with business types; behavior I have put a lot of effort into training out of myself now needs to come to the fore.
I don't know. One track is to view social nonverbal communication as ethically neutral, but eh, that... might have other problems, too. As this is an active problem for me, I clearly don't have the correct solution.
Yes. I am struggling with this right now, myself. I mean, not specifically that, but this general idea that putting effort into social bullshit that has little to do with my actual competence is dirty. It really /does/ feel dirty, and I have a difficult time articulating why.
The problem is that I have moved myself more towards management, and so getting people to do what I want really is part of 'competence' now.
A big part of this is that humility (false or not) is so absolutely core to getting along with other engineers, and so absolutely terrible when dealing with business types; behavior I have put a lot of effort into training out of myself now needs to come to the fore.
I don't know. One track is to view social nonverbal communication as ethically neutral, but eh, that... might have other problems, too. As this is an active problem for me, I clearly don't have the correct solution.
Have you done any study on our current understanding of the brain and cognitive science?
[http://www.npr.org/templates/story/story.php?storyId=1290271...]
not everyone agrees on the above model, but I think its safe to say that the part of the brain that deals with leadership existed before we invented civilization .. wolves have leadership, apes have leadership. So much of social nonverbal communication probably comes from the primitive, instinctive part of our brain, not the logical, planning part.
I think if in the past you had to deal with some really irrational people, and you were intelligent enough to be able to use logic to figure out their bullshit, at some point in your life it was probably really helpful to just reject all irrational bullshit. At one point in my life it was really helpful to me to suppress all instinct and rely solely on logic. But since then, seeing how some completely illogical people can in many situations be more efficient than me in navigating life's obstacles, I have had to learn from my mistakes and revise my behavior. I do think social nonverbal communication is ethically neutral. It's not the smartest behavior, but it is faster than the smartest behavior, and there are many situations where that ends up being more important. Not all. Unfortunately at this time I do not know of any better way to figure out which is which other than experience.
[http://www.npr.org/templates/story/story.php?storyId=1290271...]
not everyone agrees on the above model, but I think its safe to say that the part of the brain that deals with leadership existed before we invented civilization .. wolves have leadership, apes have leadership. So much of social nonverbal communication probably comes from the primitive, instinctive part of our brain, not the logical, planning part.
I think if in the past you had to deal with some really irrational people, and you were intelligent enough to be able to use logic to figure out their bullshit, at some point in your life it was probably really helpful to just reject all irrational bullshit. At one point in my life it was really helpful to me to suppress all instinct and rely solely on logic. But since then, seeing how some completely illogical people can in many situations be more efficient than me in navigating life's obstacles, I have had to learn from my mistakes and revise my behavior. I do think social nonverbal communication is ethically neutral. It's not the smartest behavior, but it is faster than the smartest behavior, and there are many situations where that ends up being more important. Not all. Unfortunately at this time I do not know of any better way to figure out which is which other than experience.
I've recently found myself in a leadership role as well, and I don't think it has to do with whether people are business types or not. Humility is necessary to fit in with peers and to get along with superiors. Confidence is necessary to influence people (be they peers, superiors, or subordinates), and you can't manage without influence.
A piece of advice I've seen in a couple places is to focus on service, whether that's service to your organization or to the team you manage, or the customer. The idea is that it takes your focus off you and your communication skills, and lets you argue from what the company or team needs.
A piece of advice I've seen in a couple places is to focus on service, whether that's service to your organization or to the team you manage, or the customer. The idea is that it takes your focus off you and your communication skills, and lets you argue from what the company or team needs.
Edit: Yes, I know this sounds kind of... angry and juvenile. Bitter. That is what I meant when I said that I clearly don't have the correct solution.
a big part of the problem is that I don't even know what most of these words I'm using mean - And honestly? I think it's "confidence[1]" that other people say they do. Of course, I know I'm not competent enough in that area to know that for sure.
>I've recently found myself in a leadership role as well, and I don't think it has to do with whether people are business types or not. Humility is necessary to fit in with peers and to get along with superiors. Confidence is necessary to influence people (be they peers, superiors, or subordinates), and you can't manage without influence.
But when you are dealing with less-experienced Engineers, your accomplishments are that influence. And when you are dealing with more-experienced Engineers, well, you should be giving them requirements, and listening to them tell you what should be done. I mean, yeah, sometimes emotional bullshit intervenes, but it's bullshit I can mostly deal with.
As an example, I came in conflict with my apprentice a while back... I am fairly certain the conflict was caused by the fact that he had learned enough that he was, well, better than me for some of the parts of his job, and that wasn't the deal when he hired on. (I mean, it also wasn't true when he hired on; he worked here for a while, and he learned a lot.) I don't know how much of it was him not adjusting to our new roles and how much of it was me not adjusting to our new roles (and how much of it was me just not being able to pay him what he was worth; he ended up getting a much better job elsewhere.)
I mean, I didn't understand how to /fix/ the emotional bullshit, but I had a pretty good idea of what it was about. that's the thing about dealing with people who are primarily engineers; I'm not saying that I am good at managing Engineers? but when I screw it up, I usually have a pretty good idea of how or why I did so.
The problem is that when you deal with normal folks, they are influenced by what looks to me like empty arrogance. It's like they have no way of judging actual skill, so they say "Why don't we do what the tall guy says?" you know, they focus on things like posture and voice and how you dress... which really have nothing to do with anything that matters.
My other problem is that I've always been way better at managing down than managing /up/ - that's the primary reason I started my own company. If you always focus on what you think is best for the company and/or the customer? you are going to come into serious conflict with the management above you. [2]
>A piece of advice I've seen in a couple places is to focus on service, whether that's service to your organization or to the team you manage, or the customer. The idea is that it takes your focus off you and your communication skills, and lets you argue from what the company or team needs.
Yeah, well, it's my company, so I think I do keep my 'eyes on the prize' as it were. But that doesn't really help when it comes time to negotiate that big new bandwidth contract (or get them to interpret that contract in my favor, after it's signed.)
I mean, that's the thing. when you are negotiating with professionals, it's their job to take as much of the surplus value out of a deal as possible. It is, by definition, 'surplus value' - the difference between the highest price I'm willing to pay and the lowest price they are willing to give me.
(the other thing about negotiating with professionals that is not fun is that they usually don't have the attention span or the knowledge of their product offerings to negotiate other than in the emotional manipulation way. I'm very flexible, and very willing to line up what I buy to what they have surplus. I'm also very willing to share what I would like, and what I can be flexible on. A professional? generally speaking, wants to collapse that down to a linear type deal, where we pick a product and hammer eachother on price until someone is exhausted. Their secrecy destroys any possible gain in value from negotiation.)
Of course, now I'm conflating negotiation with influence in general, while I probably ought to think of those things separately.
[1]Confidence as in "a confidence game" - I don't think anyone understands human interaction the way you can understand, say, how a program works. The meaning of a word someone used early in a conversation changes towards the end of that conversation. This is where I'm lost with verbal communication. The line between "saying nice things to give someone a good feeling" and "outright lying" is... I don't even see it. I have no idea where that line is or if it even exists. Does a professional think it's even possible to lie in a medium that isn't recorded?
[2]some of the things my apprentice and I disagreed about would have fallen under this. The really funny thing, for me? was that I remember having nearly exactly the same fight with my boss when I was his age, and was working in a similar role. Things... look different when you have to balance the business end. But, fundamentally, I think I can learn to deal with those conflicts, because I understood where the guy was coming from.
a big part of the problem is that I don't even know what most of these words I'm using mean - And honestly? I think it's "confidence[1]" that other people say they do. Of course, I know I'm not competent enough in that area to know that for sure.
>I've recently found myself in a leadership role as well, and I don't think it has to do with whether people are business types or not. Humility is necessary to fit in with peers and to get along with superiors. Confidence is necessary to influence people (be they peers, superiors, or subordinates), and you can't manage without influence.
But when you are dealing with less-experienced Engineers, your accomplishments are that influence. And when you are dealing with more-experienced Engineers, well, you should be giving them requirements, and listening to them tell you what should be done. I mean, yeah, sometimes emotional bullshit intervenes, but it's bullshit I can mostly deal with.
As an example, I came in conflict with my apprentice a while back... I am fairly certain the conflict was caused by the fact that he had learned enough that he was, well, better than me for some of the parts of his job, and that wasn't the deal when he hired on. (I mean, it also wasn't true when he hired on; he worked here for a while, and he learned a lot.) I don't know how much of it was him not adjusting to our new roles and how much of it was me not adjusting to our new roles (and how much of it was me just not being able to pay him what he was worth; he ended up getting a much better job elsewhere.)
I mean, I didn't understand how to /fix/ the emotional bullshit, but I had a pretty good idea of what it was about. that's the thing about dealing with people who are primarily engineers; I'm not saying that I am good at managing Engineers? but when I screw it up, I usually have a pretty good idea of how or why I did so.
The problem is that when you deal with normal folks, they are influenced by what looks to me like empty arrogance. It's like they have no way of judging actual skill, so they say "Why don't we do what the tall guy says?" you know, they focus on things like posture and voice and how you dress... which really have nothing to do with anything that matters.
My other problem is that I've always been way better at managing down than managing /up/ - that's the primary reason I started my own company. If you always focus on what you think is best for the company and/or the customer? you are going to come into serious conflict with the management above you. [2]
>A piece of advice I've seen in a couple places is to focus on service, whether that's service to your organization or to the team you manage, or the customer. The idea is that it takes your focus off you and your communication skills, and lets you argue from what the company or team needs.
Yeah, well, it's my company, so I think I do keep my 'eyes on the prize' as it were. But that doesn't really help when it comes time to negotiate that big new bandwidth contract (or get them to interpret that contract in my favor, after it's signed.)
I mean, that's the thing. when you are negotiating with professionals, it's their job to take as much of the surplus value out of a deal as possible. It is, by definition, 'surplus value' - the difference between the highest price I'm willing to pay and the lowest price they are willing to give me.
(the other thing about negotiating with professionals that is not fun is that they usually don't have the attention span or the knowledge of their product offerings to negotiate other than in the emotional manipulation way. I'm very flexible, and very willing to line up what I buy to what they have surplus. I'm also very willing to share what I would like, and what I can be flexible on. A professional? generally speaking, wants to collapse that down to a linear type deal, where we pick a product and hammer eachother on price until someone is exhausted. Their secrecy destroys any possible gain in value from negotiation.)
Of course, now I'm conflating negotiation with influence in general, while I probably ought to think of those things separately.
[1]Confidence as in "a confidence game" - I don't think anyone understands human interaction the way you can understand, say, how a program works. The meaning of a word someone used early in a conversation changes towards the end of that conversation. This is where I'm lost with verbal communication. The line between "saying nice things to give someone a good feeling" and "outright lying" is... I don't even see it. I have no idea where that line is or if it even exists. Does a professional think it's even possible to lie in a medium that isn't recorded?
[2]some of the things my apprentice and I disagreed about would have fallen under this. The really funny thing, for me? was that I remember having nearly exactly the same fight with my boss when I was his age, and was working in a similar role. Things... look different when you have to balance the business end. But, fundamentally, I think I can learn to deal with those conflicts, because I understood where the guy was coming from.
It's like entropy: the emotional bullshit in a closed system only increases. Until one person leaves, or you bleed off the pressure outside it.
With negotiation, my understanding is that the real negotiation starts weeks beforehand, because the game is about getting an information advantage, enough to make the other side's shady tactics irrelevant. All the nonverbal skills are just used to hide the math layer of the exchange. Assuming you can't dump the shady opponent for one who thinks win-win, but even then having more information can't hurt.
With negotiation, my understanding is that the real negotiation starts weeks beforehand, because the game is about getting an information advantage, enough to make the other side's shady tactics irrelevant. All the nonverbal skills are just used to hide the math layer of the exchange. Assuming you can't dump the shady opponent for one who thinks win-win, but even then having more information can't hurt.
>With negotiation, my understanding is that the real negotiation starts weeks beforehand, because the game is about getting an information advantage, enough to make the other side's shady tactics irrelevant.
You say 'shady' - I say 'professional' because this is what the big guys do. the bullshit isn't nearly as thick when you are dealing with a smaller company, generally speaking. They are less interested in wasting time.
Even when dealing with professionals, information is essential, but it doesn't make the emotional bullshit irrelevant. It's irritating, as first? I don't know if I want to do something unless I know what it costs. The negotiated price is generally 30% to 50% of the list price (but that varies a /lot/ both by vendor and by industry.) And the only real way to get prices is to negotiate with a vendor. So, yeah, I'm looking at a /lot/ of work to just find out if a business that, say, requires more bandwidth makes any sense at all.
You say 'shady' - I say 'professional' because this is what the big guys do. the bullshit isn't nearly as thick when you are dealing with a smaller company, generally speaking. They are less interested in wasting time.
Even when dealing with professionals, information is essential, but it doesn't make the emotional bullshit irrelevant. It's irritating, as first? I don't know if I want to do something unless I know what it costs. The negotiated price is generally 30% to 50% of the list price (but that varies a /lot/ both by vendor and by industry.) And the only real way to get prices is to negotiate with a vendor. So, yeah, I'm looking at a /lot/ of work to just find out if a business that, say, requires more bandwidth makes any sense at all.
So the business wouldn't make sense (but just be less profitable) if you had to pay the list price?
some businesses, it makes the difference, like re-selling bandwidth or co-lo; the margin I get on that sort of thing is usually between 10-50% so if I negotiate badly from my supplier, yeah, I'm losing money on the deal (or charging above-market rates, which considering that I'm bad at negotiation, means I'm losing even more money because the space sits empty.) - usually you have to get commercial style leases on those resources, too... and so you have all the problems of commercial leases 'Oh,' the landlord says 'you are doing well... now that your lease is up, of course, the market rates have gone up!' even if there are empty units on either side of you.
So yeah, for co-lo? it makes all the difference in the world.
Other things, like VPSs? it's just a matter of profitability... the margins on VPSs are pretty good if you don't count labor, so it'd be a matter of just not raising my bandwidth quotas like I ought and maybe spending more money on hardware.
Sometimes, there are two substitute products, one where it's traditional to negotiate, and one where it isn't... for instance, if you buy pre-assembled servers? if you aren't getting 50% off list price, you are getting it in the shorts. But, if you are buying the parts used to build said servers? generally speaking, the lowest price on the internet is pretty close to the real lowest price.
This is the primary reason why I do my own assembly; assembling computers is way easier than negotiating Dell down to a reasonable price.
So yeah; this is starting to shape what businesses I want to get into. I mean, co-location only has margin if you own the building. (I'm working on that part, but I don't have an ETA.) - so yeah, if the 'owning the building' deal doesn't work out... well, I'm not going to dump existing customers, but I am not taking more at the moment.
So yeah, for co-lo? it makes all the difference in the world.
Other things, like VPSs? it's just a matter of profitability... the margins on VPSs are pretty good if you don't count labor, so it'd be a matter of just not raising my bandwidth quotas like I ought and maybe spending more money on hardware.
Sometimes, there are two substitute products, one where it's traditional to negotiate, and one where it isn't... for instance, if you buy pre-assembled servers? if you aren't getting 50% off list price, you are getting it in the shorts. But, if you are buying the parts used to build said servers? generally speaking, the lowest price on the internet is pretty close to the real lowest price.
This is the primary reason why I do my own assembly; assembling computers is way easier than negotiating Dell down to a reasonable price.
So yeah; this is starting to shape what businesses I want to get into. I mean, co-location only has margin if you own the building. (I'm working on that part, but I don't have an ETA.) - so yeah, if the 'owning the building' deal doesn't work out... well, I'm not going to dump existing customers, but I am not taking more at the moment.
>It's like entropy: the emotional bullshit in a closed system only increases. Until one person leaves, or you bleed off the pressure outside it.
I dono. my experience has been that the emotional bullshit comes and goes, like the tide. Part of that is, well, it's not a closed system, but part of it is that social bullshit, in my experience, mostly goes away when you rationalize it;
By 'rationalize it' I don't mean 'make it rational' I mean make up some (mostly bullshit) rational explanation for the emotional bullshit. I say mostly bullshit because, well, emotions are not logical, and all logical models for explaining emotions that I know of are really terrible (I mean, not very predictive) models.
But still, assigning a believable logical explanation to a difficult feeling, in my experience, makes that feeling not so difficult anymore. It makes me feel like I'm in control of myself, and this... makes me feel vastly better. If I feel like I'm in control, or even that it's /possible/ to control, I find that letting go and focusing on something else is way easier. If I don't feel like I have control, it's really hard not to obsess. (which seems like the opposite of what I would do if I was designing the system; why should I spend effort on something I can't effect? I want to spend effort where that effort has effect. Fuck you, limbic system.)
I think the other reason it seems to come and go in waves is that there are at least two people involved. If I am in good emotional shape, I can act as a buffer for the other person's emotional bullshit, and the total amount of bullshit in the system is much less than it would be otherwise. On the other hand, if I am feeling the effects of the social bullshit at the same time as the other person, the effect is almost multiplicative.
I dono. my experience has been that the emotional bullshit comes and goes, like the tide. Part of that is, well, it's not a closed system, but part of it is that social bullshit, in my experience, mostly goes away when you rationalize it;
By 'rationalize it' I don't mean 'make it rational' I mean make up some (mostly bullshit) rational explanation for the emotional bullshit. I say mostly bullshit because, well, emotions are not logical, and all logical models for explaining emotions that I know of are really terrible (I mean, not very predictive) models.
But still, assigning a believable logical explanation to a difficult feeling, in my experience, makes that feeling not so difficult anymore. It makes me feel like I'm in control of myself, and this... makes me feel vastly better. If I feel like I'm in control, or even that it's /possible/ to control, I find that letting go and focusing on something else is way easier. If I don't feel like I have control, it's really hard not to obsess. (which seems like the opposite of what I would do if I was designing the system; why should I spend effort on something I can't effect? I want to spend effort where that effort has effect. Fuck you, limbic system.)
I think the other reason it seems to come and go in waves is that there are at least two people involved. If I am in good emotional shape, I can act as a buffer for the other person's emotional bullshit, and the total amount of bullshit in the system is much less than it would be otherwise. On the other hand, if I am feeling the effects of the social bullshit at the same time as the other person, the effect is almost multiplicative.
Adjusting your language based on context is fine, but there's a very thin line to being dishonest, even if it's just by omission.
And it's different for everybody. For me, saying you're "in the movie business" when you're doing special effects is this side of the line. Saying you're a consultant when you're not has your toes slowly creeping across - because the set of skills for each is actually different.
How much we're willing to "adjust" depends a lot on our tolerance for stories vs. facts.
And it's different for everybody. For me, saying you're "in the movie business" when you're doing special effects is this side of the line. Saying you're a consultant when you're not has your toes slowly creeping across - because the set of skills for each is actually different.
How much we're willing to "adjust" depends a lot on our tolerance for stories vs. facts.
This is one of the most useful bits of wisdom I've read on this site over the years. Thanks for this.
(or in other words: "This.")
(or in other words: "This.")
[deleted]
Precisely. Add to that the fact that the situations you most commonly find yourself in are the result of choices you make, and therefore the behavior serving you best is a result of these choices as well, and you'll be making the same point as I'm making - namely, that there are different paths to be taken, and you'd want to behave consistently with your chosen path.
Or with friends and family: Friends => "I'm a back end web developer", Parents => "I'm a programmer", Grandparents => "I work with computers".
Funny thing. It took me ages before I actually had the balls to call myself a programmer.
A few comments:
1. To me, however, a programmer is who I'm looking for, while a resume full of revenue increases and cost reductions sounds like an "anomalously high-cost parasite who types some mumbo-jumbo into Excel and PowerPoint, claiming credit for others' work". This is in no small part because you are a programmer. The vast majority of people who pay other people for work that involves programming are not programmers (and that does not make them any less smart, or any less lucrative.)
2. Abstracting a greater point from Ron Garret's career history is tricky, if only because the vast majority (by which I mean myself) of programmers will never reach his level of competence.
3. There is absolutely a chance that the value of the company which employs you will increase by ten times over the course of your employment. This chance is vastly overestimated by workers, especially in startups.
Overall, I think Yosef is misconstruing a lot of patio11's original points (though the points Yosef makes, especially about forming relationships with coworkers, are still quite true.) Perhaps the biggest takeaway: the path to success in a chip architecture career is entirely different than the path to success in a SaaS/freelancing career.
1. To me, however, a programmer is who I'm looking for, while a resume full of revenue increases and cost reductions sounds like an "anomalously high-cost parasite who types some mumbo-jumbo into Excel and PowerPoint, claiming credit for others' work". This is in no small part because you are a programmer. The vast majority of people who pay other people for work that involves programming are not programmers (and that does not make them any less smart, or any less lucrative.)
2. Abstracting a greater point from Ron Garret's career history is tricky, if only because the vast majority (by which I mean myself) of programmers will never reach his level of competence.
3. There is absolutely a chance that the value of the company which employs you will increase by ten times over the course of your employment. This chance is vastly overestimated by workers, especially in startups.
Overall, I think Yosef is misconstruing a lot of patio11's original points (though the points Yosef makes, especially about forming relationships with coworkers, are still quite true.) Perhaps the biggest takeaway: the path to success in a chip architecture career is entirely different than the path to success in a SaaS/freelancing career.
My replies to your points:
1. Do you have stats? In absolute terms, a whole lot of people hiring programmers have programmed themselves. How do you know the other people hiring programmers are "the vast majority"? (I sincerely wonder about it. I cited two numbers by two bloggers, one says it's 80% of the cases, the other says 90%. I have no idea, but I intuitively feel it's less than 50%. Are there real stats?)
2. I mentioned Ron Garret because I replied to an article mentioning him and Google as a proof of something that this example actually disproves, not because I thought it's a good example to generalize from.
3. I agree, which is why I said that people overvalue early option grants (hoping for the value to rise tenfold which it probably won't); I added to that an explanation why late option grants past the point where value can possibly rise tenfold are undervalued (because the money you make is the difference in prices, which rises with the absolute value of the stock price even if the growth rate goes down.)
I said near the end that I'm not sure I'm reading the original article as intended so you could say I misrepresent it; what I am pretty sure of is that a whole lot of people read it very closely to the way I'm reading it in my reply, and I'm writing for those people.
Your "biggest takeaway" is exactly what I'd like the takeaway to be; all I'm saying is that SaaS/freelancing career is not the only path to succeed in "programming", and that there are other paths you might want to take and you'd behave differently if you took them.
1. Do you have stats? In absolute terms, a whole lot of people hiring programmers have programmed themselves. How do you know the other people hiring programmers are "the vast majority"? (I sincerely wonder about it. I cited two numbers by two bloggers, one says it's 80% of the cases, the other says 90%. I have no idea, but I intuitively feel it's less than 50%. Are there real stats?)
2. I mentioned Ron Garret because I replied to an article mentioning him and Google as a proof of something that this example actually disproves, not because I thought it's a good example to generalize from.
3. I agree, which is why I said that people overvalue early option grants (hoping for the value to rise tenfold which it probably won't); I added to that an explanation why late option grants past the point where value can possibly rise tenfold are undervalued (because the money you make is the difference in prices, which rises with the absolute value of the stock price even if the growth rate goes down.)
I said near the end that I'm not sure I'm reading the original article as intended so you could say I misrepresent it; what I am pretty sure of is that a whole lot of people read it very closely to the way I'm reading it in my reply, and I'm writing for those people.
Your "biggest takeaway" is exactly what I'd like the takeaway to be; all I'm saying is that SaaS/freelancing career is not the only path to succeed in "programming", and that there are other paths you might want to take and you'd behave differently if you took them.
1. There are far more non-programmers than programmers. Even with a correlation between being a programmer and hiring programmers, it is plausible that the vast majority of hiring managers are non-programmers. This becomes more plausible if you step back a layer to the budget allocation for headcount rather than specific hiring decision.
Isn't it also plausible that after the first programmer hire (by non-programmer), any subsequent hiring will at least involve this first programmer?
I would even go as far as saying that an 'expert opinion' from a programmer would typically be involved in the hiring decision (be it from an external consultant, a friend or what not). Given that the non-programmer would typically realise they don't have themselves the skills to evaluate programming abilities or CVs.
I would even go as far as saying that an 'expert opinion' from a programmer would typically be involved in the hiring decision (be it from an external consultant, a friend or what not). Given that the non-programmer would typically realise they don't have themselves the skills to evaluate programming abilities or CVs.
> Isn't it also plausible that after the first programmer hire (by non-programmer), any subsequent hiring will at least involve this first programmer?
Definitely. You'll generally have to convince a programmer of your competence. Once you've passed that test, you may also have to negotiate with a non-programmer for your salary. At that second stage is when you want to be able to convince someone of your ability to multiply dollars.
Definitely. You'll generally have to convince a programmer of your competence. Once you've passed that test, you may also have to negotiate with a non-programmer for your salary. At that second stage is when you want to be able to convince someone of your ability to multiply dollars.
[deleted]
I'm not aware of many places (nor have I worked anywhere) where non-programmers hire programmers. Occasionally a hiring manager or some type is involved but as a facilitator at best.
I was having a beer in this small Brazilian town, mid-afternoon. Two girls come to my table. We try to chat ; they can't speak any foreign language and my Portuguese is awful.
- Me: What is your job ?
- The girls: Programma
- Me (for the next 30 minutes): Oh great, me too ! Which languages ? <here comes the enumeration of the 100 programming languages I know, each one pronounced in 10 different ways, Brazilian accent, etc.>
Even "Java" didn't seem to mean anything to them. Strange. I assumed they had special programming languages in Brazil.
10 years later, in Palo Alto. I read some article about Brazil society. One word catches my attention.
Programma = Prostitute. Oh.
So yes, don't call yourself a programmer. Especially in Brazil when you don't know the language.
- Me: What is your job ?
- The girls: Programma
- Me (for the next 30 minutes): Oh great, me too ! Which languages ? <here comes the enumeration of the 100 programming languages I know, each one pronounced in 10 different ways, Brazilian accent, etc.>
Even "Java" didn't seem to mean anything to them. Strange. I assumed they had special programming languages in Brazil.
10 years later, in Palo Alto. I read some article about Brazil society. One word catches my attention.
Programma = Prostitute. Oh.
So yes, don't call yourself a programmer. Especially in Brazil when you don't know the language.
10 years later, those two programmas in that Brazilian small town would still be recounting to their fellow programmas and friends that:
- There are male programmas in America (in fact, the rumor says that most of the programmas are male) and,
- The strange ritual of male programmas from America is that they start to recite these about 100 strange sounding words, and ask you if you know any of them.
- There are male programmas in America (in fact, the rumor says that most of the programmas are male) and,
- The strange ritual of male programmas from America is that they start to recite these about 100 strange sounding words, and ask you if you know any of them.
You should have told them that you specialize in back-end servers.
Curious about which city you're talking about... :)
In the end, we're all whores.
[deleted]
Not that this has anything to do with your story, but Lua was originally written in Brazil because of governmental restrictions on imported software which precluded the use of more mainstream languages. They did, in fact, have special programming languages in Brazil.
Well, they are relationship hackers.
I don't know if I'm laughing more at the confusion on your part, or the likely confusion on their part after you told them you were a programma too. Hilarious.
Haha I laughed to this. Specially because I'm brazilian.
And yes, it is the same word, 'program' is a slang for prostitute work. We programmers here joke a lot about this :)
And yes, it is the same word, 'program' is a slang for prostitute work. We programmers here joke a lot about this :)
That's pretty funny. In case anyone's wondering, the full term is "garota de programa", literally "girl of program" or "program girl". Obviously, the English is "call girl".
Normally, "programa" just means events, like "what's the program for the evening?". Here, of course, you can figure it out yourself.
Normally, "programa" just means events, like "what's the program for the evening?". Here, of course, you can figure it out yourself.
Now I'm wondering if there is a difference between call-by-value girls and call-by-reference girls.
I'm going to regret this joke, but: I posit the difference lies in how much cache you need.
well done.
If only my wife's body was immutable.
I'd love to continue this but I have garbage collection to attend to.
And they say nobody around here has a sense of humor! Happy to see it was just a matter of injecting the proper dependencies!
Whoops, came to reddit by accident.
I think you want a mutable wife. Otherwise you'll eventually have to throw her out and get a new one.
The compiler will optimize that.
Guys, please keep this stuff on /r/programming. The signal to noise ratio on HN is already bad enough.
>Normally, "programa" just means events, like "what's the program for the evening?".
This also sounds like "escort" in english. it seems to be implied that an escort would escort you somewhere. But not necessarily.
This also sounds like "escort" in english. it seems to be implied that an escort would escort you somewhere. But not necessarily.
> Obviously, the English is "call girl".
So, this conversation could have happened in America, with the title switched to "call-center associate"?
So, this conversation could have happened in America, with the title switched to "call-center associate"?
I have been a professional programmer for 32 years. When I stop calling myself a programmer I will call myself dead (if I could).
My "career" aspiration in school was to be a bearded, suspenders wearing unix admin/hacker.
I don't ever want to get non-technical. I've been a project manager, and found the work excruciatingly boring.
I've been a freelancer, and found the work mind numbingly boring.
I much prefer working for a company where I can be neck deep in designing and building challenging products.
I don't ever want to get non-technical. I've been a project manager, and found the work excruciatingly boring.
I've been a freelancer, and found the work mind numbingly boring.
I much prefer working for a company where I can be neck deep in designing and building challenging products.
I think Patrick's article is one of the best-written I've seen about the realities of the intersection of programming and business for people who have come from a strict tech background with zero business exposure. In my experience what he says is spot-on in almost every way.
Businesses exist to make money. Yes, very often making stuff is an integral part of the business model, but its still a business. To excel in a business you need to be responsible for growing its bottom line. This can only happen through increasing revenue or decreasing costs.
This probably applies more to consulting than any other field. If you go to a potential client and try to sell them on the fact that you are the best Java developer in 5 states, they are going to look at you with glazed eyes and stop listening. Tell them you think you can bring them a 10% increase in revenue with a simple piece of software, and you will get much further. This is in fact how large consulting firms make sales every day. I assure you they don't send in their developers to sell clients, they send in people who are flashy and know how to appeal to a decision-maker's interests.
I think more than anything his article explains things that are necessary to successfully convey value to purse holders who don't speak techie. If you restrict yourself to describing yourself in purely technical terms, you will sound great to other people who understand you but will never resonate with those who don't.
Businesses exist to make money. Yes, very often making stuff is an integral part of the business model, but its still a business. To excel in a business you need to be responsible for growing its bottom line. This can only happen through increasing revenue or decreasing costs.
This probably applies more to consulting than any other field. If you go to a potential client and try to sell them on the fact that you are the best Java developer in 5 states, they are going to look at you with glazed eyes and stop listening. Tell them you think you can bring them a 10% increase in revenue with a simple piece of software, and you will get much further. This is in fact how large consulting firms make sales every day. I assure you they don't send in their developers to sell clients, they send in people who are flashy and know how to appeal to a decision-maker's interests.
I think more than anything his article explains things that are necessary to successfully convey value to purse holders who don't speak techie. If you restrict yourself to describing yourself in purely technical terms, you will sound great to other people who understand you but will never resonate with those who don't.
I don't call myself a programmer because software development is not programming, probably not even mainly. Moreover, programmer gives other people a false impression of your work. Outsiders consider a 'programmer' to be a 'trained monkey that does the typesetting'. Software developer, in an all-encompassing sense, is the best description I have found for my work.
I promise you, outsiders have no concept of what a programmer does beyond, "Works magic with a computer." "Software developer" and "programmer" are equivalent to the layman.
The negative association with the word "programmer" is an industry-specific thing.
The negative association with the word "programmer" is an industry-specific thing.
Zed Shaw on corporate programmers (not mainly on titled ACLs): http://vimeo.com/2723800
I thought the general advice is to call yourself a software engineer.
Not in Canada. It's illegal here to call yourself an 'engineer' unless you're a licensed engineer. It's a protected term, like 'doctor'. So unless you studied Software Engineering, which there are many schools that teach it, and hold a P.Eng, then you can't use the term.
Technically you can also call yourself an engineer in Canada if you're an EIT (registered Engineer In Training), and you're working under the supervision of a P.Eng (Professional Engineer).
ISTM that the primary benefit of the P.Eng system is that 'Engineers' are required to uphold a precise ethical standard; passing the ethics exam is probably the most significant hurdle in getting a P.Eng after actually finishing your degree.
That said, it's also about the only hurdle aside from gaining 4 years of work experience in the field. (In theory you need to show improving technical skills, continuous learning, etc., etc., but in practice it's somewhat of a rubber stamp. (And coincidentally, at the end, you can get a rubber stamp.))
ISTM that the primary benefit of the P.Eng system is that 'Engineers' are required to uphold a precise ethical standard; passing the ethics exam is probably the most significant hurdle in getting a P.Eng after actually finishing your degree.
That said, it's also about the only hurdle aside from gaining 4 years of work experience in the field. (In theory you need to show improving technical skills, continuous learning, etc., etc., but in practice it's somewhat of a rubber stamp. (And coincidentally, at the end, you can get a rubber stamp.))
That's technically true in many US states as well, but I've never heard of it being enforced outside of the fields where many practitioners are licensed (mostly Civil Engineering, to a much lesser extent Electrical and Mechanical Engineering).
In practice, I don't believe any U.S. states attempt to regulate the mere linguistic usage of the word "engineer", the way that Canada does. Pretty much anyone can call themselves an engineer, or have the word "engineer" in their job title. What's regulated is that there are certain situations, mainly in civil engineering, in which a required document can only be signed off on by someone with a state engineering license.
It's enough of an issue in Canada that Microsoft stopped calling their peons "Microsoft Certified Systems Engineer", instead using "Microsoft Certified IT Professional".
http://en.wikipedia.org/wiki/Regulation_and_licensure_in_eng...
http://en.wikipedia.org/wiki/Regulation_and_licensure_in_eng...
My previous internship title was Software Engineer but my title was changed to "Software Designer" because someone is enforcing it.
I hate the trend of calling people who code 'engineers.' It's just not a good title for anything to do with software. And invariably people who embrace its usage seem to be trying to compensate or ignorant of what a real engineer actually does or is.
Unless your definition of 'engineer' is someone who drives a train, I don't see how 'engineering' doesn't apply to coding. At least good coding.
I was an electrical engineer before being a software engineer. There is a difference in what level of the stack I focus on now, but there is very little difference in how I design solutions and think through problems (though hopefully I've continued to get better).
Most of my electrical engineering also involved coding day in and day out.
I was an electrical engineer before being a software engineer. There is a difference in what level of the stack I focus on now, but there is very little difference in how I design solutions and think through problems (though hopefully I've continued to get better).
Most of my electrical engineering also involved coding day in and day out.
Here is an explanation that I read in a book of Steve McConnell's a decade ago.
Certain types of tasks (eg building a bridge) require an engineer to sign off on the work. And the engineer is personally liable should the design of the bridge prove faulty. An engineer is a person whose license allows them to make those representations and have it be accepted.
Most software developers lack that license, and cannot legally sign off on designs. And as an industry we don't value software development's expertise as a final say on what does or does not fly. The consequence is chronic security problems, nonfunctional software, privacy specifications, etc, etc, etc.
As a society, we are not OK with bridges falling down. But apparently we are OK with having software projects routinely overrun budgets by 100+% and still fail to deliver required functionality.
Steve McConnell makes the case in http://www.amazon.com/Professional-Software-Development-Sche... that if a true software engineering profession was recognized - not just software developers being called software developers but actual engineering certifications in the field of software development - we could begin fixing this. I don't think it will happen, nor am I totally supportive of that approach - but he makes a case worth reading.
Certain types of tasks (eg building a bridge) require an engineer to sign off on the work. And the engineer is personally liable should the design of the bridge prove faulty. An engineer is a person whose license allows them to make those representations and have it be accepted.
Most software developers lack that license, and cannot legally sign off on designs. And as an industry we don't value software development's expertise as a final say on what does or does not fly. The consequence is chronic security problems, nonfunctional software, privacy specifications, etc, etc, etc.
As a society, we are not OK with bridges falling down. But apparently we are OK with having software projects routinely overrun budgets by 100+% and still fail to deliver required functionality.
Steve McConnell makes the case in http://www.amazon.com/Professional-Software-Development-Sche... that if a true software engineering profession was recognized - not just software developers being called software developers but actual engineering certifications in the field of software development - we could begin fixing this. I don't think it will happen, nor am I totally supportive of that approach - but he makes a case worth reading.
Just one note on this, as someone with a "Mechanical Engineer" job title: The majority of people (including me personally, all my coworkers, my parents, etc.) working with "engineer" in their title, and presumably calling themselves engineers, don't have the Professional Engineer license required to sign off on bridge designs. I personally don't see any problem with Software Engineer as a title, although I'm occasionally sad that just "Engineer" is so often taken to mean software only in some places.
One of my first bosses in IT used to do steel work on large buildings. He was classically trained as an engineer. He didn't have any trouble calling computer work engineering. Considered the disciplines very similar as far as skills used. But he did have a lot to say about the legions of keyboard monkeys who couldn't find their way out of a vi instance.
Just because most people who work on computers aren't engineers doesn't make the field not engineering. Just means that most of the people that do it are incompetent at their jobs.
Just because most people who work on computers aren't engineers doesn't make the field not engineering. Just means that most of the people that do it are incompetent at their jobs.
The trend extends to other words. Sometimes I hear Programmers calling themselves Computer Scientists or Computer Engineers [1] [2] [3] when in different cases they are a Developers or a Hacker. Which they get wrong too. You are what you are. of you're acting another role you should state that you're playing that role not that you are.
Ex. Computer Scientist, who can fill the role of a Programmer.
This discussion keeps popping up [4] [5] , but the definitions are clear. I believe there's a Wikipedia article somewhere that explains all the differences.
[1] In Puerto Rico [2] http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs... [3] http://en.m.wikipedia.org/wiki/Engineer [4] https://news.ycombinator.com/item?id=5936652 [5] http://blog.hartleybrody.com/hacker-developer-engineer/
Ex. Computer Scientist, who can fill the role of a Programmer.
This discussion keeps popping up [4] [5] , but the definitions are clear. I believe there's a Wikipedia article somewhere that explains all the differences.
[1] In Puerto Rico [2] http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs... [3] http://en.m.wikipedia.org/wiki/Engineer [4] https://news.ycombinator.com/item?id=5936652 [5] http://blog.hartleybrody.com/hacker-developer-engineer/
It was explained to me (at a world leading RnD organization)
And engineer is a scientist with thumbs - though some times they have to ask the technicians to remind them how ohms law goes :-)
When I worked at a top 5 Civil engineering consultancy I corrected one of the engineers math one particular bridge in Saudi
And engineer is a scientist with thumbs - though some times they have to ask the technicians to remind them how ohms law goes :-)
When I worked at a top 5 Civil engineering consultancy I corrected one of the engineers math one particular bridge in Saudi
What's the difference between a computer scientist filling the role of programmer and somebody who is both a computer scientist and a programmer? If you can fill the role of X competently, why can you not rightly be said to be an X?
You're X AND Y. Not just Y. Just like someone here on HN who worked on their double bachelors of Math AND Physics while there was a minor called Math-Physics. S(he) worked hard for that and.
[deleted]
What exactly is an engineer then?
A lot of my friends are desk engineers at chemical companies. Not a single one is putting anything together at all with their hands, and most aren't figuring out how other people will put stuff together with their hands either. It's an almost entirely intellectual endeavor. In fact, at some places like Exxon, some chemical engineers are also internally known as economic analysts because they're mostly just trying to find ways to optimize revenue flow. If this qualifies as an engineer, why in the world does software development not, especially if what you're doing involves maintaing a server/database cluster or overseeing development practices?
A lot of my friends are desk engineers at chemical companies. Not a single one is putting anything together at all with their hands, and most aren't figuring out how other people will put stuff together with their hands either. It's an almost entirely intellectual endeavor. In fact, at some places like Exxon, some chemical engineers are also internally known as economic analysts because they're mostly just trying to find ways to optimize revenue flow. If this qualifies as an engineer, why in the world does software development not, especially if what you're doing involves maintaing a server/database cluster or overseeing development practices?
I think engineer is a reference to "builder of" or "maker of". There are plenty of other things to hate.
Are you also critical of calling 'electrical designers' engineers? The degree I'm studying for is an engineering degree.
How many classes did you take with other engineering students that other STEM majors (say, chemists) did not also take?
My CS program was "in" the engineering school but after freshman year the required curriculums diverged greatly. Sure, we both took Physics III and whatnot, but so did all of the other decidedly not engineer STEM students. Even the required/suggested math classes diverged after Calc II (with engineers skipping Calc III and taking IV instead, and most CS students taking III but not IV.
We didn't even take the same ethics courses. CS took computer ethics while other engineers took engineering ethics.
My CS program was "in" the engineering school but after freshman year the required curriculums diverged greatly. Sure, we both took Physics III and whatnot, but so did all of the other decidedly not engineer STEM students. Even the required/suggested math classes diverged after Calc II (with engineers skipping Calc III and taking IV instead, and most CS students taking III but not IV.
We didn't even take the same ethics courses. CS took computer ethics while other engineers took engineering ethics.
The business terms are "cost center" and "profit center". If you do IT for a financial firm, you are a cost to be controlled. If you do product development at a software company, your work contributes directly to profits and the more of you there are, the more profit they make. I can add that aside from software, consulting also treats programmers as profit makers although clients will see you as a huge cost. Good companies know that IT facilitates their work and should be treated with respect, but that mindset is still the exception rather than the rule. The one an interviewer told me I had asked an excellent question, was to ask how IT is viewed within this (financial) organization
In a former life, projects were paid for either from 'expense' or 'capital expenditure' buckets. Investors like expenses to be low as possible, but capital expenditure is investment in the future. Managers were always trying to creatively finagle projects in whichever bucket had some available money.
In the huge mega conglomerate where I work, I was told by my old boss to not call myself a 'programmer', as those with that title they can outsource to India, I had to have something with Architect in it to hopefully keep me employed continuing the daily grind.
Of course in all reality I am more of an architect, but when people ask what I do, do I say architect of this or that, and have to explain that, or simply computer programmer and that they get right away.
Of course in all reality I am more of an architect, but when people ask what I do, do I say architect of this or that, and have to explain that, or simply computer programmer and that they get right away.
Yeah, I usually say programmer/software engineer rather than architect. Makes explaining it a lot easier
I don't agree with the point about later stage options:
But what this misses is that you don't get paid in percentage points - you get dollars. A $100 share going up 20% to $120 means you make $20 per share. A $5 share going up 100% to $15 means you only make $10 per share.
If you join a larger company, the shares will be more expensive but you will own less of them. Percentage growth is definitely the way to measure opportunity when it comes to options. In other words: (how much I might earn) / (how much I have to pay).
But what this misses is that you don't get paid in percentage points - you get dollars. A $100 share going up 20% to $120 means you make $20 per share. A $5 share going up 100% to $15 means you only make $10 per share.
If you join a larger company, the shares will be more expensive but you will own less of them. Percentage growth is definitely the way to measure opportunity when it comes to options. In other words: (how much I might earn) / (how much I have to pay).
If you join a larger company, yes you'll get less. If you stay in a company while it grows larger and you then negotiate for more options, maybe you'll get relatively many, as you're now rather uniquely valuable to that company. What people do instead is decide that options aren't worth it any more because how much the price will rise at this point, and ask for relatively small salary increases instead of relatively large option grants. This is doubly wrong since their salary is already pretty high at that point and there's a ceiling on salaries for various reasons that I don't fully understand but which certainly exist, while there's much less of a ceiling on option grants.
The percentage that matters varies depending on the stage of the company.
For a non-public company, you have to pay the strike price, and you get stock with a particular estimated value. But you have no easy way to convert that stock into money. This is worthwhile or not depending on the ratio between price and strike price, and depending on whether the eventual price matches the current estimate.
But if the company goes public, then the equation changes entirely. Now you can take out a short term loan for stock, buy at the strike price, sell at the market price, pay off the loan, and pocket the difference. Now you really should think of it as profit/option * # of options.
The longer that you intend to stay, the better your odds are that the second way of thinking about it is right, and the more valuable your options are likely to wind up being for you.
For a non-public company, you have to pay the strike price, and you get stock with a particular estimated value. But you have no easy way to convert that stock into money. This is worthwhile or not depending on the ratio between price and strike price, and depending on whether the eventual price matches the current estimate.
But if the company goes public, then the equation changes entirely. Now you can take out a short term loan for stock, buy at the strike price, sell at the market price, pay off the loan, and pocket the difference. Now you really should think of it as profit/option * # of options.
The longer that you intend to stay, the better your odds are that the second way of thinking about it is right, and the more valuable your options are likely to wind up being for you.
When did 100% of 5 become 10?
My thoughts exactly. Although, there are sometimes stock purchase plans that limit the raw number that you can buy (usually at a discount from the public price).
No, the person he's responding to is right. In general, hiring managers don't care about bits, they care about dollars. They're going to be looking for dollars you made for other companies because that translates into dollars you can make for them.
Money. It's the universal language.
Money. It's the universal language.
That is not true across the board. Many companies are looking for specific technical talent. When nVidia is looking for someone to fill a specific niche on the CUDA team, they don't care about how much money you made for company A or B; they care whether you have the technical ability to fill the niche as they conceive of it. The hiring manager isn't naive, and already has an idea of why this position was created and what they're looking for in a hire. The interviewer is quite likely to be an engineer already on the team.
What they want you to convince them of is that you have the technical skills to fill the role. If you start talking about ROI and business value, it can be seen as a red flag that you're from a more "soft" background like business informatics, and not a good fit for the position.
Of course, if you're getting hired by someone who doesn't have a specific technical role they're trying to fill, or doesn't know what exactly they're looking for, the situation will be different. But that is not usually the case at chip-design firms.
What they want you to convince them of is that you have the technical skills to fill the role. If you start talking about ROI and business value, it can be seen as a red flag that you're from a more "soft" background like business informatics, and not a good fit for the position.
Of course, if you're getting hired by someone who doesn't have a specific technical role they're trying to fill, or doesn't know what exactly they're looking for, the situation will be different. But that is not usually the case at chip-design firms.
Sure it's a universal language. It's also a simple one that I talk myself and I don't need anyone's help with. I'm at a mixed AI/semiconductor company. We don't need brilliant minds explaining us the obvious (or, conversely, entirely opaque) financial consequences of having written this code or that. We need people who'll do it.
Now the question is how many people there are who need you to translate their dollar concerns into the language of bits, vs how many people there are who don't have trouble doing it themselves but what they do need is people who can then write the bloody program. I have no stats and I sincerely want to see some.
Now the question is how many people there are who need you to translate their dollar concerns into the language of bits, vs how many people there are who don't have trouble doing it themselves but what they do need is people who can then write the bloody program. I have no stats and I sincerely want to see some.
There's a major point in this article that not many commenters seem to be picking up on: there's a fork in the road of careers. To one side is a multilane highway over fairly level ground leading straigh to predictable suburbia. To the other side is an uneven dirt path leading through mountains and countryside to parts unknown and has many forks of its own. Neither path is right for everyone. And hardly anyone needs to be talked into the highway, as it's the default choice and the common wisdom.
The sad part comes when some bright, young up-and-comer leaves off their interesting personal projects in less used languages in order to focus on only mainstream stuff.
The sad part comes when some bright, young up-and-comer leaves off their interesting personal projects in less used languages in order to focus on only mainstream stuff.
I'm not sure which part of what I said is described by the "dirt path vs highway" metaphor, so I don't quite follow this thread. I was speaking of a more "programmery" type of career vs a more "businessy" one. Within the continuum between the two, there seem to me to be plenty of "highways" and "dirt paths" everywhere, regardless of where you are on that continuum.
You did mention choice(s), and I went off on my own with my silly metaphor. And your point about a continuum is good. It's certainly not a binary choice.
You contradict yourself. First you say: "Neither path is right for everyone"
Then you say: "The sad part comes when some bright, young up-and-comer leaves off their interesting personal projects in less used languages in order to focus on only mainstream stuff."
Why is that sad? It's just like you said, "Neither path is right for everyone." I was bright and young once and had an opportunity to go into a start-up and shape the world, but I turned it down for a mainstream job, and I'm happy I did.
There is no reason to pity my choice or mourn for me. And there is no reason to continue to foster the mentality that anyone who has never worked in a start-up is some sort of lesser developer.
Then you say: "The sad part comes when some bright, young up-and-comer leaves off their interesting personal projects in less used languages in order to focus on only mainstream stuff."
Why is that sad? It's just like you said, "Neither path is right for everyone." I was bright and young once and had an opportunity to go into a start-up and shape the world, but I turned it down for a mainstream job, and I'm happy I did.
There is no reason to pity my choice or mourn for me. And there is no reason to continue to foster the mentality that anyone who has never worked in a start-up is some sort of lesser developer.
Perhaps I should have been more explicit than trying to imply with "interesting personal projects".
Too often IRL and in communities like this I come across people who are obviously wistful that the apparent "correct one-size-fits-all career path" means doing business stuff in Java, C#, or whatever.
If you realized your options and went mainstream then you aren't who I meant. I apologize if I didn't make that clear. I've also done mainstream business stuff, and with a good company it can be fulfilling work. I certainly don't mean to denigrate that choice or those who take it.
Too often IRL and in communities like this I come across people who are obviously wistful that the apparent "correct one-size-fits-all career path" means doing business stuff in Java, C#, or whatever.
If you realized your options and went mainstream then you aren't who I meant. I apologize if I didn't make that clear. I've also done mainstream business stuff, and with a good company it can be fulfilling work. I certainly don't mean to denigrate that choice or those who take it.
Its also sad when some bright up and comer ends working for lots of little small companies, on a tiny wage when they could be earning a seriously better life working for a large company.
"earning a seriously better life" is one of the saddest phrases I've heard. You don't earn a good life, you make it.
Of course you can. For a lot people the good life is a nice family, nice holidays, not being stressed. For that you require money. Otherwise you might end up in a tiny apartment, eating cheap food, feeling quite stressed.
No. Having a nice family, nice holidays, and not being stressed do not require money. Furthermore, your counterexample of a tiny apartment and cheap food don't actually contrast your definition of the good life. You can have a nice family, nice holidays, and not be stressed while living in a tiny apartment and eating cheap food. A lot of people do so every day, all around the world.
I am that person and I'm not a bit sad about it.
The highway also gets you places where you can't feasibly get by the dirt path. Yosef is right that you can't really do chip architecture, tool design etc. in a two-person company. (Chuck Moore doesn't count.)
"Daddy, how is software made?" "Well, when a programmer loves an idea very much they stay up all night and then push to github the next day"
It is really sad when one start do programming just for money.
"Daddy, how is software made?" "Well, when a programmer loves an idea very much they stay up all night and then push to github the next day"
Resumes full of marketing-speak go onto the discard pile very quickly. I want to hear about your skills, and I want to see that you can present them effectively (which is your first opportunity to demonstrate your intelligence and aesthetics). People who claim to be programmers but talk about revenue growth and such in their resumes are always the types who want to talk to you about how they "have tons of great ideas, [they] just need a team to implement them!" Well great, then start your own company. I'm certainly looking for smart people with ideas, but we already have a product and work that needs to be done. We're not here to provide a team to implement our new hire's hand-wavey built-for-adsense get rich quick site or whatever.
Whew. OK, veered a bit into hyperbole there, but it demonstrates the visceral sort of mental response that kind of resume can provoke...
Edit: Given other comments that agree with focusing on costs and revenues, maybe the take-away is that you should really have two separate copies of your resume, and do your best to find out whether a programmer or non-programmer will be reading it before choosing which one to send. Because it seems like the reactions are essentially polar opposites. Which honestly I find surprising. I would expect that what sounds like mumbo-jumbo to one intelligent person would largely sound like mumbo-jumbo to another intelligent person, regardless of specific discipline - even if those disciplines are as different as marketing and programming. Perhaps I just haven't ever received a good resume that focused on financials.