Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kalzumeus.com

Post reply on HN
Print view View original

261–270 of 316 posts

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

#261

Post by magicalhippo »

vlunkr wrote: post #168
scarface74 wrote: post #46

Earlier quoted context omitted.

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

This shouldn’t be a problem in a business with well defined roles. Boss/manager says customer wants x. I don’t care why they want that, and I may even think it’s dumb, but I can make it happen. After all, I get paid to solve problems with code, not interpret customer requests.

> After all, I get paid to solve problems with code, not interpret customer requests.

But how to know what to solve... At least for my job, interpreting customer requests is key. The customer knows what they want, but they don't always realize what they want is not the best solution.

Often I can steer the customer to a vastly superior solution to what they initially had in mind. Not seldom this superior solution can re-use existing code, sometimes entirely.

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

#262

Post by twblalock »

elif wrote: post #32

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

The author's point is that your job is not to produce code, but rather to produce good business outcomes. Obviously you do that by producing code (and participating in design meetings and collaborating with other parts of the company in various ways).

Firefighters don't call themselves ladder and hose operators. Those are just the tools they use. Their job is to fight fires so they call themselves firefighters.

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

#263

Post by dcolkitt »

JMTQp8lwXL wrote: post #233
dcolkitt wrote: post #229

Earlier quoted context omitted.

> the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. Almost all of these concepts could easily be learned in a few weeks by a talented engineer with strong fundamentals in software design and computer science. Polyfills aren't exactly quantum mechanics. They're not some radically different mental paradigm that takes years to develop fluidity. If you already have a sound basis in…

As atomic points, I agree. Polyfills aren't rocket science. If the browser API is not defined, the use the polyfill function (at least, that's how most work, but then there's ponyfills, which don't pollute the global scope). But front-end development of complex applications isn't done in a vacuum by one person. It's done by multiple teams, possibly distributed across different physical locations. As an architect, wha…

> I could ask a handful of questions from the multitude of sections in this book, and people writing JavaScript for years wouldn't be able to answer all of them.

I think this might prove my point. There's tons of great Javascript engineers out there, who are consistently delivering business value, who actually aren't even that knowleadgable about all the details inside Javascript.

Most of the variance in quality between software engineers has to do with technology-agnostic skills rather than stack-specific knowledge. They architect well-designed, modular systems. They communicate with stakeholders. They write robust, readable, testable code. Their documentation is understandable and comprehensive. They're thoughtful about naming things. They can large codebases and keep complexity contained. They understand performance tradeoffs, and anticipate bottlenecks before they occur.

Very little of that has to do with stack-specific knowledge. A developer who does all of the above, but doesn't know all the ins-and-outs of the JS coercion model, is going to be much more productive on almost all practical business problems.

The most important skill usually isn't knowing every single detail of your underlying ecosystem. It's knowing enough about its overarching landscape to be aware of the things you don't know. As long as you know how to ask the right questions and where the limits of your knowledge lies.

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

#264

Post by candybar »

scarface74 wrote: post #184
candybar wrote: post #175

Earlier quoted context omitted.

That's fair - what I meant by it being a different career isn't that skills aren't transferable at all but that you solve different kinds of problems entirely, as distinct from a difference in stack. And if you hired me then as a mobile developer, I'd have quit, so you don't want to hire non mobile engineers into mobile roles. Language/stack is a red herring here in the sense that Java backend development is a lot cl…

I don’t know Ruby. But I can tell you the difference between having the rails of the compiler and type safe language and having those rails taken away in a language like Javascript and Python caused a lot of heartache early on.

This is fair too but I think most experienced engineers for whom stack is a valid consideration have some experience with at least one dynamically typed language and one statically typed language and can self-select out of roles if they have a strong preference either way. And I don't know anyone for whom this was an actual blocker as opposed to an annoyance (in either direction) that they got used to after a while. On the whole, I think it's less likely for this to be a serious issue than, say, the details wrt how the system is architected and how the organization is run, some of which you won't really get to know until you start.

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

#265

Post by partyboat1586 »

keiferski wrote: post #101
jpindar wrote: post #81

Earlier quoted context omitted.

That depends on who you want to be hired by. Some companies already know exactly what they need - they need some specific software written so they are looking for a programmer.

I mean, that’s sort of Patrick’s exact point - you should avoid being hired as a generic “programmer” as you’ll make far less income. Instead, if you frame yourself as an expert in a particular business problem (and have the data to back up your results), you’re far more valuable to the average manager at BigCo, or to any business in general. A good example of this is the acquihire phenomenon. BigCos often acquire sm…

For permanent roles sure. You might as well be a contractor at that point and contractors get paid more.

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

#266

Post by buboard »

vore wrote: post #246
buboard wrote: post #201

If you like your job, call yourself a programmer and build stuff you like. This article is marginally good advice for your pocket but bad for your soul. Don't be a programmer and act like a lawyer. It's one of the few jobs where it doesnt matter if you 're a dog. You create value, easily, you don't just extract it. It's part of the reason why i m a programmer and not an e.g. academic.

You do realize academia is where a lot of the research for programming comes out of, right? Seems like an unfair way to characterize academia.

not CS-related academia for me. But yeah academia requires a lot more politics, networking etc nowadays in the way that the "industry" doesnt

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

#267

Post by james_s_tayler »

scarface74 wrote: post #247
mcv wrote: post #230

Earlier quoted context omitted.

That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinion…

And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.

But if you're in a secondary employment market as opposed to startup heavy SV you might work with this person for a very long time or have a high chance of working together in the future. So the right, right now isn't always what people are optimizing for.

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

#268

Post by mcv »

scarface74 wrote: post #247
mcv wrote: post #230

Earlier quoted context omitted.

That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinion…

And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.

That's why I don't hire dead weight, or people who require handholding, but people I can trust, who can pull their own weight, and know how to learn. Someone who merely has X years in technology Y means little to me. Plenty of people manage to still be bad after years of working on the same technology.

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

#269

Post by mcv »

scarface74 wrote: post #255
bcrosby95 wrote: post #254

Earlier quoted context omitted.

Compared to what, needing to ship now and not being able to find any "qualified candidates"? It really depends upon the exact situation. We can all make up bullshit examples to make either option look stupid.

It’s “bullshit” to open req to hire a developer because you need to ship a product within the next six months and you need more bodies? Why are you hiring if you don’t need the extra people? If you didn’t need the extra people for a year until they ramp up, wouldn’t it be better just to take your time hiring until you found someone that didn’t have to spend a year learning on your dime and then leave in two years?

I needed extra people, but not merely warm bodies to fill a seat. I need people who don't need a year to ramp up, but can do so in a few weeks.

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

#270

Post by scarface74 »

james_s_tayler wrote: post #267
scarface74 wrote: post #247

Earlier quoted context omitted.

And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.

But if you're in a secondary employment market as opposed to startup heavy SV you might work with this person for a very long time or have a high chance of working together in the future. So the right, right now isn't always what people are optimizing for.

After spending 10 years at one company and suffering from not learning anything new but just as importantly salary compression, for the next 8 years, and 5 jobs, I learned the best way to make more money is to do Resume Driven Development and change jobs. While your market value goes up tremendously, HR departments insists on giving 3-4% raises to existing employees while being forced to bring in new employees at market rates.

This is the “secondary employment” market where HR policies aren’t optimized for in demand fields like software development. The immediate managers are usually helpless to do anything about it and see employees they spend time training leave for greener pastures. Being that is the reality, what other course is there but to find people you don’t have to train?

Post reply on HN