Don't Call Yourself a Programmer, and Other Career Advice (2011)

Some solid advice, some not so much. I do call myself a simple programmer. That is how I introduce myself either. Helps a lot when dealing with people whose job title require a third of A4 page to fit.

>How do I become better at negotiation? This could be a post in itself. Short version:

He misses the most important thing. The most powerful thing into negotiation is to know you can stand from the table and leave.

Yea but you're selling yourself and all of us short -- you're either a hacker, a poet or a craftsman, haven't you heard?

I think if you call yourself a programmer you can do consulting at a relatively high rate for companies who need to get some project for their profit center done. You do that, demonstrate your worth, leave with lots of money, and they might just call you again next time they need to do something for their profit center.

There's definitely ways in which being a programmer can be part of a rewarding career.

This is genuinely really good advice.

However, I want to caution against one interpretation: When you focus your attention on projects to cut costs (and risk) and grow revenue, it is possible to put that as your top priority. It should be your second.

Your real top priority should be the health and stability of yourself and your family. Ideally, this is aligned with focusing on visibly-profitable work for your employer. This is often true, but not always.

—————

Example: Suppose you are working at a company that takes code quality and automated testing seriously. This has real business value because it means that you are able to quickly execute projects which accelerate the sales team and unlock partnerships. So far, so good.

Then suppose there is an opportunity which involves taking over a codebase written by another company. The business case is strong—by taking several months to make UX improvements, you can significantly raise revenue. But, the codebase is in a poorly-documented PHP framework, has haphazardly inconsistent naming, and no automated tests. Should the company do the project? Maybe. Should you do the project? Maybe not.

Here’s what can happen: Your team agrees that its going to suck but you’re all in this together. You start on the project and you find it much harder to make progress. Because of the new toolset and lack of tests, you find it hard to maintain focus. You also lose the ability to create reasonable estimates, so your communication with internal stakeholders erodes—taking trust down with it. The number of noisy automated alerts that come in also increase, also decreasing your focus. You try to find time after work to focus on working through a PHP book, but its hard. The noisy background of your open office combines with your lack of understanding of your toolset to mean you feel useless making day-to-day progress. You talk to your manager and team lead about this. They care, but they are overworked. Its not like they they can change the open office anyway. Don’t worry—The project will be over soon. Everyone is in the same boat.

At the end of several months, you need to fill in your semiannual self-evaluation. You choke—words aren’t coming out. You’re caught between knowing you need to brag about your accomplishments and...not feeling like you have none. You’re bad at lying. After spending 2 full days on your self evaluation, you submit it mostly empty.

Soon, you are searching for a new job.

—————

So yes, when thinking about how the company views engineering, look at revenue and costs. But before that, look at the things that you need in order to be effective. Keep your mise-en-place. Use tools that fit your brain. Learn to zealously advocate for what you need.

>>> mize-en-place

Yes yes yes. And generally so much easier with OSS transferring between jobs - if you can !