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)

#131

Post by freehunter » Sun, Oct 20, 2019, 3:33 PM UTC

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.

I’ve met many programmers/engineers who are terrified of becoming management and make (what I believe to be) poor career choices trying to avoid it. Instead they get passed over for pay raises and interesting opportunities because they’re seen as being difficult to work with. When times get lean, I’ve seen those people get laid off first because no one likes working with them.

I work on a team of 50 employees. For those 50 people, there are two managers. 1 out of 25 isn’t great odds of being accidentally promoted into management without your consent.

Your working style may be right for you, I’m not questioning that. But in a thread targeted at career advice for junior engineers, I thought it’d chime in from the other side. The chances of accidentally ending up as a manager are very slim. Don’t destroy your career and miss out on interesting opportunities to avoid something that’s not likely in the first place.

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

#132

Post by raverbashing » Sun, Oct 20, 2019, 3:34 PM UTC

scarface74 wrote: post #54

Retric wrote: post #49

Earlier quoted context omitted.

I have made the jump from one language to another several times on the job. It’s considered lower risk to use someone on the team than higher someone new. It’s also going to take a while to higher someone and get them up to speed. After a year you might not be as experienced as someone using the same stack for 5+ years but the difference is not that extreme. Further stacks tend to share quite a bit. Knowing SQL, HTML…

Languages are easy. But do you think you could jump from systems programming in C to mobile programming on Android “easily”. I’ve seen people jump from Java to C#. You can see the difference in their coding style, them not taking advantage of the features of the language, reinventing the wheel because they didn’t know there were popular packages that would do it for them, creating horrible inefficient queries and pra…

> You can see the difference in their coding style, them not taking advantage of the features of the language, reinventing the wheel because they didn’t know there were popular packages that would do it for them, creating horrible inefficient queries and practices using EF etc.

That's why code reviews are a mentoring opportunity. Help your colleague level up.

(Also there should be team dialogue about how to solve some problems more efficiently, I mean, if I was unsure of something I would go and ask colleagues for some guidance, or you would go and do some research on your own)

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

#133

Post by pascalxus » Sun, Oct 20, 2019, 3:35 PM UTC

Much of what he says about business and programming is all true, at least in theory for well run, competitive businesses. But, for instance, sometimes in govt, they never actually calculate the ROI of a project or employee. They just think: well, we have money that needs spending, let's higher some people to build some seemingly useful software. Determining what's useful and what's not ahead of time is harder than it seems.

But, the part about most programmers not being able to implement FizzBuzz is incredibly false based on my experience. I've worked for over half a dozen average companies (plus some government too!) in the bay area and I've never once met an engineer who couldn't implement FizzBuzz. They're able to program FizzBuzz and much much more complex things, far more than job requirements need. Not only that, but I've never even met an engineer candidate (i've interviewed dozens) that couldn't do either FizzBuzz or other basic programming tasks. So, I really don't know how you people are finding all these unqualified candidates.

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

#134

Post by djsumdog » Sun, Oct 20, 2019, 3:36 PM UTC

> There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.

Andrew Yang brought this up in his interview with Joe Rogan a few months back; how people in The Bay will basically say, "Yes, we're trying to automate away these jobs." And to some extent, we're trying to automate away jobs in the tech industry as well.

Look at the Sears (Willis) tower. That building was originally dedicated to all the manual processing needed by Sears Roebuck & Co to process store and catalog orders; logistics for the largest retailer in America .. the Amazon of the early 1900s. A few decades later and the tower was mostly rented out to other customers. Even when things were still going good for Sears, they were able to drastically reduce the number of people they needed using machines and automation.

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

#135

Post by georgeburdell » Sun, Oct 20, 2019, 3:36 PM UTC

ryandrake wrote: post #111

FeatureIncomple wrote: post #87

Earlier quoted context omitted.

- 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…

I think the key is that you need to motivate them for why they should hire you. I recently went through the job interview process and I got ghosted by a company with a job opening on LinkedIn that I know I was qualified for. I reached out to the recruiter and within a week I had an interview scheduled, and within two weeks I had an offer.

Sometimes you need to just get a human's eyeballs on your resume.

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

#136

Post by bhldev » Sun, Oct 20, 2019, 3:36 PM UTC

NiKMic wrote: post #59

claimred wrote: post #45

>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 been doing that one for your entire career. I've always been a bit baffled by notions like that. How in the world one becomes a professional in a foreign programming language tech in 6 months? It feels like every modern realworld battleworn programming stack (ecma, c++2x, .net, jvm w/…

Because companies don't care about how 'clean' you code is, what design patterns you use or what cool new technology you are using. They just care that you manage to release quickly so the company can start making money. So even if you don't know the best way to do things or the best pattern to use, as long as you can hack something together that works reasonably well for some time then you're good enough. Sure, it m…

Depends on the business model. If you sit on the bleeding edge all the time maybe (even if you don't you should strive for the newest possible for the skills and budget if only for retention and hiring).

But if the whole point of the company is to build some generic software that's configurable then absolutely the inside and code matters because it's a hard requirement. You could build specifically to one type of configuration but it would not solve the other. And that means generic, abstractions, reuse as part of the business case not just some nice to have for clean code.

So it very much depends. It's also possible to take it too far. As for internal release dates I have always considered them bullshit ever since I heard executives talk about how they pad the time. The more layers of management the more padding and if everyone works separately in different teams the more the padding. Developers are better off ignoring internal release dates and building the best software they think possible to not compromise on quality. They can cut scope but at the end of the day the software better work. The only thing you shouldn't ignore is warning people if it will go over time. Since 50% of software goes over time that's expected.

Either it's good or it isn't either it works or it doesn't and the timescale devs are used to (sprints, days, stories etc) don't have any bearing on reality. If it takes a month more because it has to that's how long it takes. The concept of "MVP" or feature set is totally separate from a good piece of software; once you get there you can release and iterate and improve. And it's called "minimal" for a reason if you stop there your software is sunset. The features and improvements have to keep rolling.

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

#137

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

comicjk wrote: post #114

elif wrote: post #47

Earlier quoted context omitted.

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"). Th…

Speaking of railway logistics. Railroad car repair billing is esoteric and complicated. I wrote software dealing with this at one job.

https://www.railinc.com/rportal/documents/18/260737/CRB_Proc...

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

#138

Post by Consultant32452 » Sun, Oct 20, 2019, 3:36 PM UTC

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…

It's also not true with respect to people noticing what you've been doing with your career. A programming language isn't just a language, it's also a culture. I've been writing Java professionally for almost 20 years. I can definitely tell when a person isn't a "java programmer." I am struggling to describe exactly what I mean, but the best metaphor I can come up with is it's kind of like hearing someone speak with a heavy accent. It can all be technically correct, the grammar is perfect, but you can still tell it's not native.

Sometimes this is good. It can bring in new/interesting/helpful ways of thinking about problems to come up with better solutions. Sometimes it's bad because anything that's a little jarring or unusual impedes support and maintenance by "native programmers" in the same way a heavy accent can impede communication.

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

#139

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

elif wrote: post #118

scarface74 wrote: post #107

Earlier quoted context omitted.

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?

And whether they are “unprofitable” or not doesn’t mean they don’t either seek to become profitable or get bought out - ie your livelihood is still based on capitalism.

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

#140

Post by School-Cotton » Sun, Oct 20, 2019, 3:39 PM UTC

mongol wrote: post #43

bdowling wrote: post #37

Earlier quoted context omitted.

Profit centers consist of people who can directly attribute revenues or savings to the work that they do. Everyone else is a cost center. No, it's not fair.

Sales people are usually profit centers, as I understand it. Without sales, no profits.

Without the janitors there would be no profit either.