Don't Call Yourself a Programmer, and Other Career Advice (2011) • Hacker News Board

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

#181

Post by milquetoastaf » Sun, Oct 20, 2019, 5:12 PM UTC

dominotw wrote: post #123

amirathi wrote: post #60

This is fantastic practical advice for software engineers early in their career. Here's some more based on the common pitfalls I see, - Don't apply to 50+ companies at one go thinking only a % of them will call you. Choose ~5 companies, do a lot of homework about their business & write to key people at these places telling in ONE paragraph what you can do for their business. If it fails, choose next ~5 and so on. - O…

> write to key people at these places telling in ONE paragraph what you can do for their business. Do you have an example of this? What can you possibly do for their business? Do key people respond to random solicitations for a job. Don't you still have to go though their original Leetcode interview process. I am really not seeing what the advantage of this approach.

Maybe for small stage startups or deliberately tiny, private ventures. Otherwise, yeah, might as well just apply via the normal channels since the employees will forward your request to HR/hiring anyway.

OP's advice is wishful thinking. I highly doubt they themselves took that approach

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

#182

Post by clarry » Sun, Oct 20, 2019, 5:12 PM UTC

tjpnz wrote: post #38

ensiferum wrote: post #23

"Engineers are hired to create business value, not to program things." Yup writing software should be the last recourse and only to be used when all the other solutions to problem are not viable.

That's a function of experience. Junior dev me was coding 80-90% of the time but 10 years in it's 10-20% of the time.

Or a function of your position in the hierarchy of things. Tell a programmer in a subcontracting company to create business value when the main contractor's architects & sales team have -- without your input -- already decided exactly what feature must be implemented..

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

#183

Post by scarface74 » Sun, Oct 20, 2019, 5:16 PM UTC

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.

I was once interviewing for a job as a senior engineer/lead role. The CTO - my eventual manager - was asking me a lot of high level technical questions even though he was a very competent developer.

Then, another developer who had been there for a decade asked me how I would go about writing “address validation routines” - It was a real world problem he was facing. I told him that I wouldn’t. That’s not the vertical the business was in. The best code is the code that you don’t have to write. Address validation software is a solved problem and there are plenty of third party CASS solutions and yes they cost money but being able to write address validation software is not the company’s competitive advantage or its differentiator in the market. It’s better to outsource it. That’s one less thing we would have to maintain and debug.

The developer wasn’t impressed. The CTO was.

I’ve spent my entire career asking questions and making sure we were building the right things.

My first job out of college over 20 years ago I was the sole developer on a project to write a data entry system that was used by a new department with a dozen new employees. I had to actually talk to our potential client to gather specs myself.

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

#184

Post by scarface74 » Sun, Oct 20, 2019, 5:20 PM UTC

candybar wrote: post #175

abtinf wrote: post #158

Earlier quoted context omitted.

> It was a little painful but everything shipped on time. Your last sentence would seem to contradict the entire body of your comment. You describe mobile development as a fundamentally different thing, but then your first gig was to work on a large project, the result of which was shipping on time at the cost of a “little” pain.

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.

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

#185

Post by coldtea » Sun, Oct 20, 2019, 5:20 PM UTC

scarface74 wrote: post #44

arbuge wrote: post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer?

>Why would a company choose someone who doesn’t know the stack they are using over someone who does?

Because a stack defined programmer is a limited programmer...

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

#186

Post by coldtea » Sun, Oct 20, 2019, 5:23 PM UTC

braindeath wrote: post #160

bhldev wrote: post #121

Earlier quoted context omitted.

I notice this a lot on apps in the subway (who doesn't) and the app just dies A lot of problems in life can be simply avoided this is no different... If you're getting that tiny last bit of differentiation because you're 90% market share and you can afford to hire people to solve that exact specific problem then great. But that isn't most places. Most apps would do better to 100% avoid the problem and just say "No In…

> Most apps would do better to 100% avoid the problem and just say "No Internet Connection" if there's no WiFi or 3g. Lol we are in such a bubble.

If the bubble is large enough, it's the others who are in a bubble, and we're just "in the world"...

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

#187

Post by scarface74 » Sun, Oct 20, 2019, 5:26 PM UTC

booleandilemma wrote: post #173

scarface74 wrote: post #44

Earlier quoted context omitted.

Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer?

Agreed. The job doesn’t exist to train you.

It’s more nuanced than that. Most job reqs have “must haves” and “nice to haves”.

My current job had one must have - C#/MVC/Web API and some Javascript experience - their current tech stack. Nice to haves were React, the fiddly bits of AWS, and Python. I was immediately useful because I was strong in the must haves, had a little AWS experience, and knew nothing about Python or React.

I’ve since leveled up on the nice to haves except for React, I refuse to jump on the $cool_kids bandwagon of front end development. Especially seeing that everything else I listed, pays more, and doesn’t change as often.

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

#188

Post by ben509 » Sun, Oct 20, 2019, 5:31 PM UTC

astura wrote: post #113

amirathi wrote: post #103

Earlier quoted context omitted.

Yes. With 50-company approach you increase the absolute number of first callbacks you get (hence everyone thinks it's optimal). With 5-company approach you increase the odds of actually getting through to a single job offer. Think about it.

>you increase the odds of actually getting through to a single job offer You haven't AT ALL explained why your "~5 companies approach" is more likely to get you an offer. It's not. That sort of approach would be less likely to get you an offer anywhere that I've ever worked. 999 times out of 1000 you don't have a clue to a company's current business needs just by looking at public information, even if you had insider…

It's because E(#offers) = #applications * P(initial_contact) * P(successful_interview | initial_contact)

The ~5 companies approach tries to optimize P(ic) and P(si) at the expense of #apps.

The 50 approach optimizes only #apps because it assumes P(ic) is low, and disregards P(si).

Especially P(si) is very important because the interview's purpose is to determine that you're a good match for them. If they're just another company you spammed an application out to, that becomes very obvious.

The ~5 companies approach forces you to have already selected them because you think there's a solid business case for them to hire you. And you can make that case during both your initial contact and the interview, thus maximizing P(ic) and P(si).

> 999 times out of 1000 you don't have a clue to a company's current business needs just by looking at public information

I'd say it's more like 9/10, but that absolutely makes the case for the ~5 company approach. You're filtering out the ones that have a poor recruiting process.

It takes a lot of time to put together a good application and you have to focus on companies that will not only be responsive but follow through all the way to the hiring decision.

So focus on companies that make it clear what they do and what the position entails will tend to maximize P(ic) and P(si).

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

#189

Post by scarface74 » Sun, Oct 20, 2019, 5:32 PM UTC

coldtea wrote: post #185

scarface74 wrote: post #44

Earlier quoted context omitted.

Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer?

> Why would a company choose someone who doesn’t know the stack they are using over someone who does? Because a stack defined programmer is a limited programmer...

As a person who was responsible for hiring in a previous role and I still sit on a lot of technical interviews, I didn’t care if you were “limited” to the stack we were using as long as you could get the job done without six months to a year of training.

If you started your career learning Java 20 years ago and you kept up with the latest trends of Java, you could still find a job now. The same is true for C# around 15 years ago.

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

#190

Post by sdenton4 » Sun, Oct 20, 2019, 5:40 PM UTC

JMTQp8lwXL wrote: post #167

arbuge wrote: post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of th…

That's more a question of overall area of past work, though, than particular language or framework. If you've been working on frontend stuff, problems of layout, matching redlines, response latency, etc, should be in your deck regardless of which programming language you've been using.