Live data from Hacker News

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

kalzumeus.com

191–200 of 316 posts

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

#191

Earlier quoted context omitted.

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

Now not only do you have a less effective developer who takes time to ramp up, you’re also taking time from senior developers.

I’m not saying this is always the right course and of course this doesn’t scale to larger companies, but my first project at my current company a week in was to develop a feature from scratch which ended up involving coding an API for the front end developers, writing an ETL process that used both Redshift (AWS OLAP database), and MySQL designing the schemas, configuring the AWS resources with CloudFormation, setting up queues, messages, lambdas, dealing with the vendor we were integrating with and learning the business vertical. How much longer would it have taken if instead of already knowing their stack - C# WebAPI, MySQL, and AWS - I came from a Java/Mongo/GCP background?

They needed someone useful now to get a feature out that they wanted to charge customers for.

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

#192
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 th…

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

Where I work it's about 8/50.

But I don't have to worry about being a manager - because they only get hired from outside.

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

#193
post #66

Earlier quoted context omitted.

Sure, jumps like that are not as bad as you might think. Style wise the code is often poor, but users don’t really care about the code. I started with Object Pascal on Mac OS 8/9 which forced you to do a lot of low level tasks like deal with Handles and suffer through a cooperative multithreaded OS. Rewriting the network layer from AppleTalk to TCP/IP was closer to systems programming in C than you might think. I hav…

The jump is huge. Web development has a completely different model than mobile development. In web development, losing a connection is a failure case. Developing for mobile it is expected. Especially for enterprise apps. Logic is usually distributed, syncing is required, knowing which is the source of truth etc. This is really an example of hiring someone who has experience and hiring someone who thinks “it’s easy an…

They are different, but I don’t think networking is one of the major differences.

Website backends often have significant dependence on other services that can be down. Further standalone apps can have zero network dependence or a lot. So having written both, and similar code for each, I don’t feel the networking side is all that different.

If anything networking is probably the largest similarly between them.

PS: I did some iOS development in my spare time even worked with some old J2ME, so I assume Android is fairly similar.

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

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

First, developers rarely become tech fluent in 6-12 months.

Second, startups don't have 6-12 months.

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

#195

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…

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

I’d say yes, with an asterisk.

The trick is to treat finding your first job as a search problem, not a dice roll. You’re searching for employers that need someone with your skills and experience, and those same employers are also searching for you.

The asterisk is that I think this “5 company” approach is meant to be aimed at companies that don’t have the resources to do very “active” searching. A rule of thumb: if the company has a specialized university recruiter, they are probably too “active” for the list, if you’re a new grad with no intern experience.

You don’t find these companies on job boards or LinkedIn. You find them by “searching”, like an investor. You can begin by looking for local VCs, the look at the portfolios of those VCs, then at the LinkedIn history of people who work at those portfolio companies. By now you probably have seen 20 interesting companies, and you can proceed to whittle it down to 5 small companies that will already know you have the requisite energy and enthusiasm, since you went through the real effort of finding and choosing them.

TLDR: yes, but not if your five spell out FAANG.

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

#196
post #47

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.

Do you not consider finding out what the person asking for things actually wants to be a hard problem to solve?

I live to build things and continuously fend off attempts to slide me into management, but I find actually programming things to be only half the part of the puzzle.

Humans are extremely bad at articulating what they want and will generally tell you the wrong thing up front because they haven't thought it through fully.

A day spent with a stakeholder carefully picking their brains and properly crafting a plan can be just as satisfying as a day of straight coding - sometimes more so.

(tbh this is probably also why I find UX work so interesting - getting a user to click on a button is considerably harder than making the button in the first place)

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

#197

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…

Really senior level is about talking to people; “Knowing the ecosystem well” (if by that you mean a specific tech stack) is almost irrelevant. Senior is more about solving the right problem than solving the problem “right”

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

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

Point taken, but the language is not the thing I would hire for anyway. It's the environment and skill-set beyond the language. A mobile developer even requires a completely different set of instincts to be successful than an engineer who's got work experience building scalable backend systems. C++ running across 1000 inter-connected systems is not the same C++ compiled down to run on a gaming console with limited CPU cycles to spare. C++ shared across iOS and Android is also different because Android requires that you bridge the library across Java and iOS may require an Obj-C layer if you're in Swift.

If you spent your whole career writing code in Python and you wanted your next job on iOS, my concern wouldn't be, can you learn Swift in a short time. My concern would start at something as simple as how you would cache data when the network connection times out. Or can you manage your data models in a way that can maintain 60fps scrolling, something iOS engineers pride themselves in achieving. Of course all of this can be learned, but my point is that it's more than the language.

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

#200
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?

Because someone is smarter or better at the job in general that the lower quality specialists they can find. It's very hard to find a good generalist. If you can be a good generalist, you're exponentially more valuable than a generic specialist. I have done mostly backend work in Python, but in my current role I've worked in the frontend with Angular, I've debugged critical issues on our iOS app, I've fixed our AWS infrastructure, I've moved us away from dragging files into windows boxes to CI/CD, I've helped architect solutions, I've worked with our customers, I've led efforts across multiple teams, etc.

Being a "Python Programmer" in no way measures my value to the company, in fact, it necessarily limits what I'm actually capable of contributing to the company. If you can show that you can add value outside of a specific tech stack, you're worth the few weeks to learn a new technology. And yeah, it is basically a few weeks to get up to speed and be a contributing member of a code base if you don't know the technology. 6-12 months to know all of the details if you're a solid engineer.

Post reply on HN