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.....
Don't Call Yourself a Programmer, and Other Career Advice (2011)
211–220 of 316 posts
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#212Earlier 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…
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#213Earlier 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…
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…
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)
#215Earlier 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…
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)
#216Earlier 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…
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)
#217Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#218Earlier 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…
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)
#219Earlier 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.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#220Earlier 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.