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)

#111

Post by ryandrake » Sun, Oct 20, 2019, 3:03 PM UTC

FeatureIncomple wrote: post #87

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…

- 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. This is one of the best advices for people starting their careers. This comment should be at the top of this thread! EDIT: Formatting

No, no, no, arghh no! No matter how much you research, study, network, and prep for any one special particular company, if you are the one to reach out you’re going to get ghosted a certain percentage of the time. If that percentage is around 90-95%, which is what it is in my experience being in the industry for 20 years, then focusing on 5 companies may mean zero callbacks. You need to cast a wide net, especially as a junior engineer.

I’ve tried this strategy of targeting an insider in my network and pitching myself through him. Several times. It has never worked for me. Ultimately it ends up at “Whelll, nice talking to you! Next step is to apply for this job id online. Good luck!!” What does work is if conpany initiates contact, THEN you go through your network to gather information about the role and hiring manager, and so on. Having an insider pushing for you after company has already expressed interest has been a lot more reliable to me.

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

#112

Post by matz1 » Sun, Oct 20, 2019, 3:04 PM UTC

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…

You can as well argue that you are expert in programming that your expertise are not limited in a solving a particular business problem. This way you open up yourself to more company or any business in general.

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

#113

Post by astura » Sun, Oct 20, 2019, 3:09 PM UTC

amirathi wrote: post #103

Dumblydorr wrote: post #95

Earlier quoted context omitted.

What if you truly need employment and you are a run of the mill beginner? Is that 5 company application approach still optimal?

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 information, a random insider probably doesn't know the current business needs of anyone outside of their day-to-day job. Even if you did know the company's current business needs, unsolicited job applications from strangers to people who aren't recruiters mostly go straight into the trash bin. If I personally received unsolicited job application from a stranger, I'd probably just ignore it. The most I'd ever do is reply telling them to apply via our career site like everyone else.

Plus what exactly would you say as a "run of the mill beginner" for "what you can do for their business" that would catch anyone's attention that a quality resume and cover letter submitted though the job portal wouldn't?

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

#114

Post by comicjk » Sun, Oct 20, 2019, 3:12 PM UTC

elif wrote: post #47

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?

Because there are hard problems to solve. I'm into computer science not capitalism.

Pet peeve of mine: solving practical problems often involves capitalism in our system, but that doesn't mean practicality is capitalism. If you're writing ad code, you're working on capitalism only. If you're writing railway logistics code, you're doing practical work that any society needs, capitalist or not. And yes, this might involve understanding customers (or as a different system might call them, "people").

The important question would be "is this work useful," not "does this work involve capitalism."

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

#115

Post by imhoguy » Sun, Oct 20, 2019, 3:14 PM UTC

mobjack wrote: post #50

goatinaboat wrote: post #30

Earlier quoted context omitted.

The marketing department is a cost centre. The accountants are a cost centre. HR is a cost centre. Middle management is a cost centre. But the logic of profit centre vs cost centre is only applied to engineering departments, or workers in general. That’s really all you need to know about it.

Marketing is a huge profit center. Improving efficiency in marketing spend can bring in millions in new business value. If you can do that, it will definitely be noticed by the business.

Joga classes in the office can improve employees and management efficiency and their comfort of life so such spend can bring in millions in new business value by healthier and happier staff. Is joga trainer a profit center?

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

#116

Post by Finnucane » Sun, Oct 20, 2019, 3:16 PM UTC

cool-RR wrote: post #24

chasingthewind wrote: post #19

Re: Profit Centers vs Cost Centers I was once on a team that maintained a SaaS application that was in some sort of bizarre super-position of "cost center" and "profit center" a few years back. The company technically sold the app and made money from it, but they also tended to give it away almost for free as long as the buyer was going to be paying lots of money for the company's $FLAGSHIP_BUSINESS_SERVICE that inte…

My best conclusion is that there is no definition of "cost center" and "profit center" that makes sense. I challenge anyone to give me such a definition. This is as good a place as any to put this: Peter Drucker originally coined the term "profit center" around 1945. He later recanted, calling it "One of the biggest mistakes I have made". He later asserted that there are only cost centers within a business, and "the…

Most places I’ve worked had the attitude that profit center = sales and everyone else was a cost to be controlled or eliminated. It shouldn’t be really surprising that management thinks management is the most valuable function, and actually making the product is not.

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

#117

Post by bcyn » Sun, Oct 20, 2019, 3:16 PM UTC

thestepafter wrote: post #84

scarface74 wrote: post #82

Earlier quoted context omitted.

You’re not worried about their mobile experience until the app fails to work in a tunnel because they are expecting an always on connection or they have half their records on their mobile and half on their server and need to figure out which to use or they never had to figure out a syncing algorithm because you usually don’t have to sync things on the web since you never expect long periods of not being connected. Ed…

I would argue that this isn’t solely the responsibility of the programmer. This is where testing and QA comes in. Also, these are pretty basic considerations when building mobile apps and I would argue that they aren’t language specifics.

While it's not solely the responsibility of the programmer, most of the responsibility should fall on the programmer.

It's a much more efficient system for the programmer to own UI/UX and for testing and QA to simply verify. In contrast the the programmer doing whatever, and leaving the full responsibility of UI/UX to the testing & QA cycle.

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

#118

Post by elif » Sun, Oct 20, 2019, 3:17 PM UTC

scarface74 wrote: post #107

elif wrote: post #104

Earlier quoted context omitted.

You don't know anything about my particular situation, and happen to be very wrong. But assuming the role of your rhetorical me, there are thousands more companies just like "mine". they all provide paychecks.

And how do those companies earn money to give you a paycheck?

Most of these paychecks come from unprofitable companies. I'm not sure what point you are wanting me to walk into. Are we still talking about programmer management strategy?

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

#119

Post by 0x445442 » Sun, Oct 20, 2019, 3:17 PM UTC

cool-RR wrote: post #102

leetcrew wrote: post #90

Earlier quoted context omitted.

not sure this is an airtight definition, but think about employee skill vs revenue in a particular department. if you're selling software, you would expect revenue to go up a lot if you increase the overall skill of the developers. if you're a restaurant, you probably don't see a huge increase in revenue from hiring a very good website designer. basically, how hard is it to get people who do a "good enough" job? mayb…

I understand that we're mostly agreeing, and I think that we both have an intuition for what it means for something to be a profit center. Still, I'd like to show a gap in what you said: You talk about what kind of increase in revenue you'd have if such and such people did a better job, and what kind of ROI you'd get from each department. But the question is, an increase relative to what, or an ROI relative to what?…

I agree with you 100% and have attested to the same claims on other threads. With small exceptions, businesses exist to make profit. The whole discussion going all the way back to the original terms should be recast as "ROI positive centers" and "ROI negative centers". From that perspective I would agree, it's better to be working for an "ROI positive center" in the company. And even though it might seem the security compliance department is ROI negative, if the alternative is being shutdown by a government agency or paying heavy fines then it really is ROI positive; it just might be harder to make those calculations up front.

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

#120

Post by SpicyLemonZest » Sun, Oct 20, 2019, 3:18 PM UTC

scarface74 wrote: post #98

SpicyLemonZest wrote: post #80

Earlier quoted context omitted.

It’s like saying “well, we’re an agile company, so we prefer to hire people who know standups and sprint planning”. In principle they will ramp up faster, sure. But it’s just not a useful thing to select on, and if you do select on it you’ll end up with a weird monoculture.

Knowing an ecosystem well on a senior level won’t happen in a few weeks. But to your example, I’ve seen developers who couldn’t adjust to developing where they had a rapid release cycle because they were use to the big design up front. How you develop software where you don’t have all of the requirements for the next year is a completely different mindset. Even on comments on this post, I see people who aren’t actual…

I agree the problems you're describing are real and important to select for, but just requiring agile experience won't help you there. Lots of people practice a weird form of agile development, where they go through all the motions of fast iteration, but almost all tasks consist of non-negotiable internal dependencies and not value delivered to a customer.

I'd argue a similar thing is true for tech stacks. If there's some correlation between knowledge of all the fiddly bits of C++ and ability to write clean, performant systems-level code, I've yet to see it.