Hacker News Reader

Comment by makeitsuckless | Hacker News Reader

> A good developer can pick up any language or platform in a few weeks

Yes and no. There's a major difference between "picking up" and actually being good at something. If you have nobody on the team that is either already intimately familiar with the language/platform, or has experience with various languages/platforms, you're going to be spending a lot of time figuring out how to do stuff properly instead of just building stuff. And if you are a startup with a limited runway, that difference is crucial.

View on HN

The famous Norvig piece "Teach Yourself Programming In Ten Years" touches on this:

> In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.

I've always liked that quote, because it really goes both ways. We see languages change over time, when we learn what one language is good for and start to incorporate some of that thinking into another. e.g. we're seeing `class` syntax in es6, but that's been present in many other languages for a while. PHP has been adding improved support for `list()`, which is basically its way for managing tuples, something very popular in the Python world. The right way to make this progress isn't by just blindly dumping syntax from one language into another, but by learning many and having it change the way you think.

> In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for.

A couple of things:

- A good programmer won't just write C++ in the style of Basic.

- A good programmer wouldn't just use C++ to accomplish a task, there must be a legitimate reason, performance, etc.

I myself have done exactly this, I just wrote a Ruby C-extension to make my program faster and I definitely didn't write it in the style of Ruby.

Well even the best programmers have deadlines or have to work with something outside their main expertise. I've written and deployed CSS and Windows batch scripts but I'd be pretty stuck trying to compose either without reference materials.

Thanks for the "Teach Yourself Programming In Ten Years" article, just read it. Yeah I've seen first hand how people code after "Teach Yourself Programming In X Hours/Days" absolutely horrible. There is no quick way to learn GOOD programming. Between, good article OP.

>>you're learning to accomplish that task.

If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination.

In two ten year sprints you will be due for retirement.

No offense, but you are living in a kind of unfortunate corner of "industry".

Where I am sitting, you absolutely have 10 years (or more) to give toward a specific cause, and the path of the software developer is one of lifelong improvement.

Stuff like "the rate at which tools are changing" doesn't matter too much, because that stuff is just surface-level knowledge, not deep knowledge.

I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.

This is why I got out of areas of webdev etc that don't value deeper knowledge. I can't say how much more satisfying it is to be learning stuff that is useful for 10 years instead of the webdev framework of the day/month/year.

webdev requires deep knowledge, it just may be a kind of knowledge you aren't interested in. Placing more value in your own pet interests is more than a little condescending.

Thats why I qualified by saying "areas" of webdev.

Deep knowledge of what? The way different browsers render things?

All of the Web dev I've been involved in is pretty straight forward stuff to manage records in a database or make it easier to interact with the records on a browser.

The only thing remotely complex was 3d rendering. Perhaps I have a narrow view of what is considered web dev now.

"Webdev" is not fundamentally any different from any other kind of development that involves a client and server component. It just happens to be served in a web browser. You need the same underlying knowledge as for other (common) types of software development.

It certainly can. But it feels like a lot of the Web dev scene is people chasing their tails around writing yet another JavaScript library that does the same thing as one they're replacing but with slightly different syntax.

and how is this different than dev in general?

What have you moved in to from webdev?

Lower level areas - graphics, drivers. I'm a contributor to Servo, which is new tech but if successful will be around for at least a decade.

>>I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.

I didn't mean to say that. Everybody has individual choices, and I respect yours.

And not all of us would like to code when we are 50+. Personally I would like to retire early to take time off for other things. This is entirely a personal perspective, and might change from person to person.

It's funny. I'm the CEO of a professional services company and I'm much more interested in coding nowadays than I'm nearing 50 than I was in my youth.

the game developer Jonathan Blow is also 43 years old. you wouldn't happen to be him, would you?

if so, cheers to you! keep up the good work. if not, same sentiment regardless.

Yep, that's him, given his profile in HN and http://the-witness.net/news/

This is the sort of attitude that is responsible for the proliferation of "cargo cult" style programmers. People in industry who don't understand anything at a deep level and barely understand what and/or why they do what they do most of the time. They just find code -> paste code -> tweak here, tweak there -> quick test -> move on. Now you have systems which contain massive technical debt and are not well understood or designed. People like this view everything as a black box.

No, no thanks. I work in the medical device industry, but this applied everywhere. If you don't understood your tools at a deep level please, study. Go off and write some trivial stuff before you infect important systems with your ignorance.

> Now you have systems which contain massive technical debt and are not well understood or designed.

If that's indeed a trend, then this industry is moving towards a pretty bad place.

I think it's a trend in that today we have a lot more programmers than we did 30 years ago, and much of today's programming languages and tools are highly abstracted. Most programmers don't have to know much about how their computer or OS works to get something up and running. It's good for productivity, and I'm not recommending that we go backward, but there is a consequence to making things (seem) easier.

It's much worse for contracted stuff, in-house development, or B2B products, because in all of those cases user experience is not really a big deal and barely-functional, slow systems will continue to be used. In addition, many developers being hired at such places are being hired by people who are not, themselves, programmers, and therefore aren't screened the way they would be at a software company.

Our tools keep changing but we're all still relying on the same 50-year-old data structures and algorithms (or, I guess, in many cases, solving the same problems in a less effective way because many of us aren't familiar with them). That one gives me pause.

Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.

Its not just about having math and other computer science information. Age related discrimination is a huge problem in this industry. Most of the programming jobs out there don't involve detailed interaction with algorithms and data structures in every day work. And if it does, its not like the 80's where you had to visit a library to learn about an algorithm. Access to knowledge has become very cheap and quick. Having a lot of information in your brain in itself has no value.

Young people are ready to work lower salaries, will do work on weekends, late nights and in general a lot more agile in a lot of issues.

In fact the 10000 hour/10 year rule itself is subject to a lot of assumptions like access to information being expensive in terms of time and effort, so having someone on the team with that information would help. These days you have stack overflow and a dozen places on the internet who can much of that at a far more lesser price.

Its getting easier over time to build systems and solve problems.

I can't tell if you're trolling or naive. No serious SDK, Framework or API is built without deep know-how of the domain. You atleast need to be great at data structures (or OOP), design patterns, language design.

Unless you're doing the literal bottom-barrel of engineering work where you don't involve algorithmic know-how, there's no escaping having deep engineering.

Perhaps what offends me most is the notion that "you can just google/stackoverflow it". No you can't. If you don't know your tools, every problem will be a nail and your only tool a hammer. You're not being fast, you're being hasty and creating a lot of waste by moving very slow on the aggregate. It's this attitude that introduces massive bugs in the system because an engineer copy/pasted code without knowing it's implications.

Development is knowledge working; you need to invest in your knowledge tools else you're just moving really slow and you don't even know it.

> Having a lot of information in your brain in itself has no value.

Having a lot of unstructured information in your brain has no value.

If you learn a lot, and then start putting patterns together and build more complex rules out of that - that has value. And by the way, the result of that process is the kind of thing that could be easily transferred to other particular areas.

http://www.aft.org/sites/default/files/periodicals/LookItUpS...

Looking things up won't do you any good if you don't understand what you find, and you're going to waste time flailing around if you're unable to recognize the class of problem you have (which is what algorithms are for -- they're solutions for classes of problems).

Also, people without understanding of CS fundamentals often unwittingly write dog-slow code.

> Having a lot of information in your brain in itself has no value.

If you think of it as inert info, the accessing of which in the brain is equivalent to reading it on a web site...

But it isn't. Brains, especially in respect to deeply understood domain knowledge, change in response to how they're used.

Experts' minds create shortcuts to information in their area of expertise.

Having more information means having the ability to synthesize it, gain epiphanies that would otherwise be overlooked--and reading someone's blog post about their epiphany isn't the same as having it yourself.

I don't know where all this "age related discrimination" is happening, but I'm well past your "due for retirement" cutoff and I haven't seen any of it. Maybe it's because I stay out of the frothy race that is web-dev, and focus on system software, where experience is valuable and it's not just possible but mandatory to take your time learning the fundamentals.

As someone who just 'picked up' a rails 3 app to add an online order form, I agree that, while you may be able to 'get stuff done', you'll be slower than someone who has experience, no matter how senior you are. At least for a few months. I banged my head against tasks that a RoR developer would have finished far quicker.

However, by being willing to train senior folks (and I'm talking my book here, as I am a senior developer), you gain two things: access to a larger pool of applicants, and the value of cross pollination. (I've seen a lot of ORMs in my time, and concepts translate between them.)

How to choose whether to train or not? It depends on the length of your runway (longer means you'll have more time, obviously), how many other current folks have knowledge of the solution (and can offer code review or other guidance), how committed the applicant is (tough to judge, but desiring employment vs wanting a contract is a proxy), how far you are pushing what you are building (if it is a normal use case--crud app for rails--a book and a few days may be enough training time. If it is not--high traffic erlang application--you may have a harder time training someone up without extensive partnering), and how hard it is to find someone who has experience with your current technology (there is an opportunity cost to training someone, but there is an opportunity cost to having an empty seat as well).

Certainly any senior developer worthy of the name is going to be able to pick up a language and be productive with it in a few weeks. However, they'll make mistakes, just like anyone will, that may require rewriting later.

Junior folks are a whole different ballgame.

I have to agree with you... we all go through it. I always considered myself pretty good with JS (very senior), when Node/npm started getting bigger (3-4 years ago), a lot of things really made me feel out of my depth. You get used to it, you observe, learn and adapt.

Most of the concepts of application development will always apply, and context is everything.

On the flip side, I've met plenty of developers who have absolutely no desire to look at different languages, tools or ideas. To me, that's what is really scary. I can't imagine having that mindset and where I will be in a decade if I did. I just turned 40 a few months back, and feel like I am learning about as much as I did in my 20's. The difference being the objectivity on what to dive deeper into with regards to learning more.

Interesting, I read this as being open to hiring good developers even if they don't know your current platform/language. You can train that, and if you have existing expertise then you can pair them with someone who is experienced to teach them the nuances.

This is definitely what I was getting at. My admittedly fairly small sample makes me think I'd rather hire someone who appears to be an excellent developer in general and train them on a new language/ framework than someone who appears mediocre but already has experience.

I think the same applies to junior developers as well. Someone who is eager to learn, and does so on their own time to try and learn new things will give you far better results than someone who only has whatever experience they gained via internships, or as classroom assignments.

The best developers I've ever met all have one thing in common. They've all written stuff outside of school and the workplace. Not that everyone keeps doing so, but they all have at least when starting out.

Totally agree. Good programmers have a lot of knowledge that transfers well between different languages and environments in my opinion. Put another way: language syntax is accidental knowledge, but how to program is essential knowledge.

More here: http://henrikwarne.com/2014/12/15/programmer-knowledge/

Your ability to train an employee is going to be hampered by the size of your company. You need someone with both the experience and the time to already be on payroll.

If that's the case, most companies would just give that person the work to do. If they've already got the time and experience, very few managers [in the real world, at least from my experienced] have the foresight to use that person to train another developer. Usually they'd just give that person the work until there's so much work they can't scale and then someone else would be hired to pick up the shortfall... Of course, the first developer is still so snowed under that they have little to no time to mentor the new guy. So they look for someone who may be experienced in the language but only a mediocre developer by definition. In real world terms, it appears to be expected that a senior developer can just be dumped into the empty seat and get on with it - thus, the expectation also appears to be that this senior developer needs to understand the language and pick up the business knowledge quickly enough to be productive without costing more than absolutely necessary.

If one of the intended features of a language is that it can be picked up quickly, that certainly helps. I'd suggest that this is a feature of golang and historically modula-2.

+1.

I don't think there will be meaningful slowdown from taking a 'good developer' with a lot of experience in Rails and throwing them into Django development. It takes very little time to figure out the proper way to do something when you're already heavily versed in the core concepts and ideas behind what your doing, in this case MVC web development in an OO imperative language.

Where this doesn't work as well is when you take a 'good developer' who's worked mostly in C++ writing game engines and throw them into web development using Clojure. It's hard to figure out the proper way to do something when your not even sure what your trying to do, or what terminology to use to efficiently google the question.

I think the author is primarily referencing the former situation, not the later.

I love Rich Hickey's analogy of the language as an instrument. I am a pretty good musician and can make decent sound from most instruments within a few hours. That doesn't mean I can make music with it. For example, the tambourine has over 90 unique sounds it can generate in the hands of a master. Concertos have been written for the instrument. I can do about 3 of them rather poorly.

Better to hire experts than polyglots if you want to make a concerto. Actually, it is better to design great software with the advice of great players then let them rock out while you stay out of their way.

Seems like an odd caveat. Why would you pick something nobody on the team is good at? Who made that silly decision to begin with. I'd expect at least one person is good/familiar with the language chosen.

> Why would you pick something nobody on the team is good at?

This is more likely than you may think...

"I want to learn Ember.js, so even though I'm proficient at using Angular.js let's write everything in Ember.js instead. Then we can spend months chasing our tail learning all of the 'Gotchas' of Ember.js. Also, just to make things interesting, let's use a bleeding-edge version of Ember.js. Also let's do this at a time when articles on Ember.js that are just 4 months old are already out-dated and no longer apply to the current codebase."

Though I doubt that a warning on HN will deter such people.

It will make a good 'lessons learned' blog post later.

I'm sure that the investors in such ventures are thrilled at the idea of paying developers to spin their wheels for a few months in order to create material for a "lessons learned" blog post.

sometimes I get the impression that a large portion of software developers act like consumers in their professional lives. Find shiny, try shiny, discard for new shiny. Doesn't matter if it's a personal gadget or something the company is counting on.

hammer.strike(nail['head'])

Well, I've been in the situation where nobody knows any of the frameworks around to achieve your goal and you just kind of have to pick one and hope you're right so that's another possibility.

Well, that's a different can of worms than, "I have a tool in front of me that I know how to use and is an appropriate tool for the job, but I will consciously decide not to use it. This will cause me much grief."

I've worked at a couple of startups that failed for that reason. The CTO picked something he wanted to pad his resume with, rather than a good technical choice.

Fair enough. I seems like a terrible decision from the start. But to me that connects deeply with people shipping stuff. If you're all learning the intricacies of some new tech, you're probably not shipping as much as you could be.

Oh, I agree that it's a terrible decision, but people make horrible decisions all the time. Many times they won't even admit it was a bad decision in hindsight.

Resume-building, probably. Or else nobody on the team is familiar with any of the tools to accomplish the desired goal (e.g., you want to make a SPA and none of you have ever done it before).

There's also a difference between a really good programmer just starting in a new language and a really bad programmer having 10 years of experience in the language. I'll take the former, please.

But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about.

That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.

"No good developer would choose to start a new project in earnest in a new language they don't understand well."

There are plenty of developers who chose to do just that, eg:

PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET).

WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang).

Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).

Those are clearly weekend projects that took on a life of their own. Hence the qualifying "in earnest" in my post.

Whatsapp certainly wasn't a weekend project that took on a life of it's own. More of a multiyear project where the guy figured he may as well use the best technology because he'd have plenty of time to learn it. From startup school:

..why did you choose Erlang?

Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.

Picking up a language for me involves reading the O'Reily book cover to cover -- every single word. That way I get familiar enough with the language that I don't spend weeks doing things "the wrong way" just because I'm used to doing things a different way in another language. This, and the initial ramp-up time usually takes a few weeks. For really big languages like modern C++ it would probably take longer than for node or something like that.

Agreed.

I'd say "You can pick up 90% of any language or planform in a few weeks." That last 10% though is some edge-case/deep understanding that you won't even know about until you really need it (and it's probably shown up in production).

I think that different languages have their own level of how much edge-case there is in total, as well as how much may be exposed edge there is visible now vs later. It's akin to having icebergs of different volume, but unlike icebergs, also different proportions of 'ice' below and above the water.

I agree. I've seen an experienced new hire "pick up" a new language, and the result was them writing non-idiomatic, difficult-to-understand code. They know they want to do Z, but they don't know the language's way of doing it, so they do X and Y to get to Z, making it difficult to understand their actual intentions.

This can be solved with code reviews, in which a developer who is experienced in the language can teach the new developer the right way of doing things. Of course, you shouldn't wait until the new developer has written thousands of lines of incomprehensible code before doing a review.

I totally agree with that, in theory. In practice, sometimes teams can be spread too thinly to allow adequate code reviews, developers can have egos associated with their titles that prohibit constructive criticism, and management can favor "if it looks like it works, it works" style of project delivery. These real world scenarios bias me towards people who know the language they will be using daily.

I think the the context of this statement refers to hiring, as opposed to choosing what language/platforms your team should build with.

All other things equal, for a startup, I'd rather hire a smart freshman over a middling candidate who had five years' experience with the language/framework I wrote my app in.

Plus, there are a number of startups where the speed at which you can "build stuff" is not the limiting reagent towards success. Even if you were the fastest builder in the world, if you don't build the right product, no one will pay you money, and you'll run out of runway. (Dozens of student "startups" out of the University of Waterloo run into this exact problem during every four month term.)

A good developer + a patient, knowledgable and humble mentor is a winning combo.

As the old joke goes, a good developer can write FORTRAN in any language.

I think this point should be: - A good developer is open to any new language or platform and willing to learn.

I think the point is that a good developer is happy to start using a language/framework because it is the best tool for the job (regardless of their experience using it), rather than just sticking to what they know.

I think that's probably more useful in a start up. But I go more for the 'get shit working and see what happens' approach to developing. I mean, making it look pretty is what iterations are for.

maybe. or whatever.

"Best tool for the job" is not a knowable truth. Best for what time frame? For what shifting array of tasks?

Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>

Good point. FB may be an existence proof that the utility/power of the language, at a certain point, is not necessarily the bottleneck in execution.

Can we say this? A startup is more likely to fail because it couldn't iterate fast enough than because it didn't start with a powerful enough platform/stack?

If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...

Is that really the lesson to take away? They have lots of projects that are not in PHP and designed a superset of the language with features it didn't have and their own VM for it, among other things, so, while they may have overcome the issues, I'm not sure that it didn't matter.

this may be a great way to go about in hackathons where one has very less to loose and success is greatly rewarding. if nothing, at least you learn something new. contrarily, in a startup a lot of things are on bet - money, opportunity, time - or may even mean difference between success and failure. it all boils down to reward-risk tradeoff.

I thought it meant "as long as s/he has done something similar with a similar tool".

Ruby/Python/PHP web CRUD, that kind of thing.

I think it's believable, as long as you have at least a few weeks to play around first. As long as designs are similar, it shouldn't be too hard to port.

Also, any number of "from X language to Y language" pages exist, and they should give you the most obvious caveats.

I'm glad you made this distinction. With enough time, yeah, sure, we can be "good" at any of them, but I've seen companies bring people on without a developed skill set in a particular technology only to find out the ramp-up time to be as efficient as someone familiar with it to be much longer than they bargained for.

agreed. it's really about lifecycle.

near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.

In a startup context it doesn't matter, the technical founders should be able to whip something up in whatever tech stack as you're ramping up. Once you have some funding, employee #1 or 2 should be an expert and be able to bring in all the cargo-cult best practices for that tech stack and teach the rest of the team.

Depends on the platform. To me, that's a big measure of how well-designed a platform is that I can pick it up quickly and stop being bitten by its idiosyncrasies.

For example, I've been supporting old ASP.Net Web Forms projects for about a decade and I'm still getting stunned by that damned monstrosity.

true. this can be compared with learning math(or any foreign language for that matter). you can have a one page cheat-sheet of all the rules and formulas, but that can only help you solve textbook problems. there are tricks and caveats that are learnt only by practice. googling 'how-to' is a very slow process, even with stackoverflow.

Reply on news.ycombinator.com