Do call yourself a programmer, and other career advice
yosefk.com
yosefk.com
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.
(or in other words: "This.")
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.
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 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.
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.
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 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.
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.
[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.
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.
- 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.
And yes, it is the same word, 'program' is a slang for prostitute work. We programmers here joke a lot about this :)
Normally, "programa" just means events, like "what's the program for the evening?". Here, of course, you can figure it out yourself.
So, this conversation could have happened in America, with the title switched to "call-center associate"?
This also sounds like "escort" in english. it seems to be implied that an escort would escort you somewhere. But not necessarily.
- 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.
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. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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).
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.
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.
The negative association with the word "programmer" is an industry-specific thing.
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.
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.
Money. It's the universal language.
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.
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.
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.
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.
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/
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
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.
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?
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.
http://en.wikipedia.org/wiki/Regulation_and_licensure_in_eng...
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.))
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.)