Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kalzumeus.com

Post reply on HN
Print view View original

91–100 of 316 posts

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

#91

Post by scarface74 »

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.

So now we are going to spend more on development and probably rework because the developer decided he was just going to wrap the website in a webview and call it a “mobile app” because he didn’t think through these scenarios. Anytime that you have to go through the development -> QA cycle more then once it costs money and time.

That’s kind of my point. Learning a language is easy and for the most part useless without knowing the frameworks and architectural best practices.

I don’t know what Android has, but iOS has built in frameworks for handling syncing. If an Android developer didn’t know all of the built in frameworks available to them and re-invented the wheel, that would also be a waste of money.

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

#92

Post by ensiferum »

matz1 wrote: post #86
ensiferum wrote: post #75

Earlier quoted context omitted.

Yes programmers program but the point was that programming new software should be the last option in solving a problem and only done as a last recourse.

>programming new software should be the last option Sure, but thats not the concern of programmer.

Often it is when unfiltered business requirements come down to the engineering department and individual programmers. Then the first thinking should be: how can I avoid solving this problem? If the problem needs to be solved then the next question is "how do I solve this without writing a single line of code". If software is required then the question is how to use and apply already existing software. If there's still need to write code then finally we can start thinking howto write the least amount of new software.

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

#93

Post by srazzaque »

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…

I agree with you, it's not how technical people are hired. But, I think it's entirely necessary in certain contexts, once we realise the software world is bigger than just Web.

Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master.

So I'd be inclined to add disclaimers to the idea that "after 6 to 12 months nobody will ever notice".

This might be the true if you're moving from 1 web programming gig to another web programming gig, but the author himself acknowledges the vastness of software out there that underpins every aspect of industry.

So - if you're going to be working on enterprise middleware in investment banks, or embedded systems on airplane simulation kit, or APL, or missile guidance software - but all you've done is web... then tech stack does matter. Insofar as being familiar with the paradigms, standard patterns and unique industry norms.

The problem is that some middlemen (ie recruiters, HR or non-technical hiring managers) do not understand that, for instance, Java and C# are somewhat interchangeable, but C# and APL are not.

Fantastically written piece in all though, lots of great stuff in there that I wish I had either known (or stopped denying!) earlier in my career. But specifically on this point I think it's a dangerous idea to imply to undergrads that deep, hard-earned experience in both tech and domain can be overcome in such small time scales.

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

#94

Post by usaar333 »

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…

Agreed on this generally being solid early career advice. Some of it is outright wrong though at more senior levels. E.g;

* Not giving salary expectations upfront lead to a waste of time if the company expectations are below yours

* It's not really relevant how bad many other programmers there are since you'll tend to look at switching to "better" companies, not worse.

* This is a bit too negative on equity grants for companies with strong product market fit (mostly article just hasn't aged well with companies staying private for so long now)

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

#95

Post by Dumblydorr »

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…

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

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

#96

Post by palerdot »

scarface74 wrote: post #91
thestepafter wrote: post #84

Earlier quoted context omitted.

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.

So now we are going to spend more on development and probably rework because the developer decided he was just going to wrap the website in a webview and call it a “mobile app” because he didn’t think through these scenarios. Anytime that you have to go through the development -> QA cycle more then once it costs money and time. That’s kind of my point. Learning a language is easy and for the most part useless without…

The argument made here is a good generalist tech guy would definitely think these things beforehand as much as an android or iOS guy ... That is language knowlegde !== problem solving ...

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

#97

Post by SkyPuncher »

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 think this post had tons of good advice, but I feel like programmer vs engineer is a micro-optimization.

There's no standard terminology and nearly every company has a slightly different definition of terms.

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

#98

Post by scarface74 »

SpicyLemonZest wrote: post #80
scarface74 wrote: post #44

Earlier quoted context omitted.

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?

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 actually willing to actually talk to the customer to decide what they should work on.

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

#99

Post by jamesjguthrie »

jamesjguthrie wrote: post #78
rco8786 wrote: post #56

Earlier quoted context omitted.

This is entirely company dependent. My team is primarily Ruby and we hire folks with no ruby experience all the time.

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

Yeah downvote a guy looking for work. Thanks.

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

#100

Post by friedman23 »

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

> It feels like every modern realworld battleworn programming stack (ecma, c++2x, .net, jvm w/e) is filled with nuances and quirks which, as it turns out, an engineer _must_ know about to be able to bump revenues a little bit and to call themselves a professional.

I think you are overestimating how important those nuances are. The differences between Python and Ruby are not significant. The differences between Java, C#, or Golang are not significant. If you are a trained software engineer and have coded with one managed memory language, one garbage collected language, one typed language, one untyped language, one functional language and one object oriented language you have seen 99% of what there is to see. Most computer science grads should graduate having programmed C, Java, and Python

Post reply on HN