Live data from Hacker News

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

kalzumeus.com

211–220 of 316 posts

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

#211

Earlier quoted context omitted.

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”

And then you end up re-inventing the wheel, setting up servers and spending more on maintenance and development because even though your entire company is already on AWS, you didn’t know you could just click a button and make that entire part of the product someone else’s problem.....

Come on. Even highschool kids know that AWS exists, that doesn't make you "senior". How did you go from "Knowing an ecosystem well on a senior level won’t happen in a few weeks." to an example of someone reinventing the wheel? That's absolutely an example of non-senior behavior. But I was talking about e.g. someone that doesn't know Spring, or Angular - it seemed to me you were saying "can't hire a non-Spring-expert as senior if we're using Spring and he doesn't know it".

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

#212

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…

This has been my experience as well.

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

#213

Earlier quoted context omitted.

They're not rare. I know a ton and many still write Ruby. Willingness to work on brownfield Ruby projects is rare; as with other similar systems like Django or roll-your-own Express stuff, such systems strongly tend towards chaos and a lack of maintainability after a certain point if they haven’t already had strong leadership end-to-end. In my neck of the woods, the folks who you want doing that work don't want to do…

> They're not rare Depends on how you define rare. Exceedingly uncommon at the very least. stares at a pile of 150 resumes Ruby is a language languishing from being embedded in a few niches, having poor performance, and otherwise being unremarkable, imo. Ruby was made with the idea that picking it up would be easy (which it is), leading to less incentive to learn it. Putting Ruby in the job description gives you appl…

Calling Ruby "unremarkable" is a significant understatement, I think. For my money nothing in common usage approaches the same kinds of metaprogramming and solving-a-category-of-problems-at-once nature of a really comfortable and dynamic Lisp as does Ruby. (Clojure isn't in common use.)

I get that that's not what you want, you want somebody to close tickets, but that's not Ruby's fault. And most of the people I know still working in Ruby are at a level where that kind of grunt work just isn't worth their time; most others have, of course, moved on.

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

#214

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

His assertion is wrong, by the way, only some programmers are contributing to job losses in other domains. I expect that many of us are just building products.

Perhaps that's their way of making themselves feel better, when they say that everyone's doing it.

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

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

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

That is a great point. I’ve also had the experience of working for a short time on a system, knowing that I would hate for it to become a regular part of my work. So hiring someone with experience is one way to mitigate staff turnover from undesirable tasks.

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

#216

Earlier quoted context omitted.

And then you end up re-inventing the wheel, setting up servers and spending more on maintenance and development because even though your entire company is already on AWS, you didn’t know you could just click a button and make that entire part of the product someone else’s problem.....

Come on. Even highschool kids know that AWS exists, that doesn't make you "senior". How did you go from "Knowing an ecosystem well on a senior level won’t happen in a few weeks." to an example of someone reinventing the wheel? That's absolutely an example of non-senior behavior. But I was talking about e.g. someone that doesn't know Spring, or Angular - it seemed to me you were saying "can't hire a non-Spring-expert…

There is a difference between “knowing it exists” and knowing what it can do. No, despite what a bunch of old school netops guys who watched an ACloudGuru video and now can click around and duplicate their on prem infrastructure on AWS (and cost more) think, it’s much more than just hosting VMs.

And you kind of proved my point....

If you don’t know the wheel exists, you don’t know you’re reinventing it.

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

#217

Earlier quoted context omitted.

I need a job and can write code in nearly any language. Hire me?

Yeah downvote a guy looking for work. Thanks.

Don't take it personally. It's not you that's being downvoted; it's your comment.

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

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

>In web development, losing a connection is a failure case.

That's changing with the advent of progressive web apps. It's possible to write web apps now that are robust in the face of network problems, e.g., the web app renders and is functional even without a connection.

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

#219

Earlier quoted context omitted.

Come on. Even highschool kids know that AWS exists, that doesn't make you "senior". How did you go from "Knowing an ecosystem well on a senior level won’t happen in a few weeks." to an example of someone reinventing the wheel? That's absolutely an example of non-senior behavior. But I was talking about e.g. someone that doesn't know Spring, or Angular - it seemed to me you were saying "can't hire a non-Spring-expert…

There is a difference between “knowing it exists” and knowing what it can do. No, despite what a bunch of old school netops guys who watched an ACloudGuru video and now can click around and duplicate their on prem infrastructure on AWS (and cost more) think, it’s much more than just hosting VMs. And you kind of proved my point.... If you don’t know the wheel exists, you don’t know you’re reinventing it.

Look, I don't even know what your point is. I thought you were claiming "you can't/shouldn't hire someone who doesn't know well the technologies that you currently use". If it's not that, then don't mind me, I was debating something else/ I misunderstood your point.

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

#220

Earlier quoted context omitted.

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…

>In web development, losing a connection is a failure case. That's changing with the advent of progressive web apps. It's possible to write web apps now that are robust in the face of network problems, e.g., the web app renders and is functional even without a connection.

I’m not questioning whether you can do it with web technology. But you still have to design it where both your business logic and your data can live on the device and it can queue submitted data until there is a connection available and if multiple people are updating the same record, knowing how to merge the information or knowing which one takes precedence. I’ve even seen cases where the logic depended not on just the record, it depended on knowing which fields were updated by the device when it was disconnected and the prior value of the field to make sure that the user had seen the most recent value before they updated it. If not, someone on the back end had to do a “manual merge conflict resolution” by calling both people.
Post reply on HN