Ask HN: Hot & Useful software skills for novice converts?

10 points by ashr ↗ HN
I have a couple of friends who for different reasons (valid to them) would like to get into software development. One of them has a Master's degree (economics) and the other has a PhD (Biology). While both of them would love to first get into school (under-grad/grad) to get a solid foundation in Computer Science, they can't as they need to keep making money. They are fine working at the entry level in the industry. They have asked me for the skills that they should learn that will help them contribute to their future employers in a meaningful manner and thus earn their pay.

While I have my own ideas, I would like to know what the smart and pragmatic people on HN have to say.

To start the discussion: * Which programming languages: Java, C#, Ruby, Scala, C++ ... * Which application domain: Web, Desktop, Mobile etc * What are the skills that are in the demand most as per your experience? What kind of skill set you are looking for in the entry level programmers when you hire? * What are the skills that will be valuable in the long run?

24 comments

[ 3.5 ms ] story [ 107 ms ] thread
Regular expressions. They don't take a long time to learn, and can save you endless work in a wide variety of domains.
Indeed that is a useful little skill to have.

I am looking for skills at a somewhat higher level than regular expressions though. For instance, like some of those mentioned in the question above.

They make a nice, organic entry point into a lot of higher-level programming concepts, including some of the languages you list. I believe it makes more sense and is more motivating to start by solving problems rather than learning software development in the abstract.

You can solve a lot of problems with pattern matching, and the ones you can't solve will then lead you to other interesting places.

idlewords is right. You may think regex is too low level, but like i said in my comment, you want to learn things that you can use anywhere. Almost every programming language has regex support.

Plus, regex is hard for a lot of people -- even programmers. Most developers copy/paste regex into their code, rather than write it.

And his other point, that it teaches you problem solving is important too. That's what software development is, solving problems. Learning a language won't help you solve problems.

You have to ask yourself, "what problem do you want to solve?"

The first thing I ask people when they want to start learning to program or build systems is: What kind of system do you want? You have to want a solution to a problem to really get good at programming. You have to create a problem and then solve it.

Regex is good at that because when you understand regex, it's easy to find problems that it solves. Imagine wanting to find all files on your computer that contain phone numbers or email addresses. Something like that is very useful and you can do it quite easily with regex.

Good point. That reminds me of how Programming Languages/Compiler construction courses helped me understand how high level programming languages worked.

And it is a good way to get started with problem solving. Thanks for elaborating.

Their prospects are going to kind of suck at first.

If I were to do a crash course, I'd say:

    Java/C#
    Code Complete/related software engineering books
    Eclipse/Visual Studio
    svn/cvs
You'll notice that there's nothing overly exciting there. I think it's most important for them to get the standard set of skills that'll give them the best chance of working in software development. That means the boring stuff that most people here would be "too good for." Everyone's a code monkey for some portion of their lives, the lucky ones just get it out of the way early.

And they might also consider the QA -> Engineering route. QA sucks (I can attest), but it's a good way to start working with software. If you're lucky, you can even move into regression tests, regression frameworks, etc.

I'm a QA at a startup and I don't think it sucks. I really enjoy my job and I think it requires variety of skills. In order for you to really excel at QA, you need to know a thing or two about programming, databases, client-side scripting( JavaScript in my case), usability, TDD and etc. This whole combination makes it really interesting. Can you share your experience or opinion on why you think it stinks?
Can't speak for the parent, but from my experience, most developers think QA stinks because they have had to do it on the side. If you have to do it on the side, you usually don't have time to do it properly and write tests / scripts or do coding stuff in general, you are simply reduced to doing rote testing. Rote testing stinks.
My experience, as a developer in huge multinational that has been involuntary moved into QA: it sucks. You might need sysadmin skills but not dev skills. You don't get to solve the problems, just identify them. If you do overstep the boundaries by suggesting a solution, you'll quickly be put back in your place. And lastly, although the automation carrot is often dangled the deadlines are always tighter than the human resources for manual testing so you'll just have to test it over and over and over again.
Well first off, i'm sorry for that off the cuff comment. I didn't mean to downplay the importance of QA (the world would suck without it, for sure) nor the importance of QA positions. It just isn't development, which was what I was looking to do. I agree very much with Joel Spolsky's thoughts on the subject. http://www.joelonsoftware.com/articles/fog0000000067.html

As to my story, I was placed into QA in the "choice" program because they misrepresented the role (it was an internship). The skills required listed C programmer, but on the first day, I was told there would be no programming.

The first few weeks I configured test beds. This was a lot of installation of server stuff (mostly following check lists) and configuration of networks. This was very IT'ish, and though important (and it sparked my interest in how exactly networks work, which I followed up on my own time), it wasn't what I was hoping for.

I got into automated testing shortly thereafter because they needed someone to do it and I had a lot of programming experience. I coded in Java using an IBM testing thing and a company framework provided by another QA person. This framework was buggy and _completely_ undocumented. In one place, there were 14 nested If/For's. There were obvious design flaws. Not only that, the person who wrote it was wholly unavailable (constantly busy). She did find time to do reviews when I only had an hour left in the internship to respond to them. Ironically, one complaint was that I recreated her functionality in some parts (if only I'd KNOWN about it!)

So, in short, my experience dictates that QA in large organizations means people that don't give a crap and do the bare minimum. I don't know if this is a QA problem or a large corporation problem, but no thanks to either.

Languages: start with one of (Ruby, Python). At some point learn: C, Java. Also fool around with Erlang/Scala. That's the short version.

The economics guy could probably do well with R and some stats stuff... there's apparently beginning to be a big market for that kind of thing.

I think web stuff has a lot of jobs, and there's lots of room to get in at an entry level and work your way up. Something like mobile probably requires more skills at the get-go.

Okay, so here again is an opportunity for me to talk about my company, but I will try to avoid it.

Here's the deal. The web is the future. So for application domain -- the web is where it is at. And the web includes mobile. Mobile devices are web devices. The whole point of the web was to enable mobility in a standard protocol -- mobility of information, digestion of information and communication of information between any device, whether that device is a computer with a browser, or a cell phone, or a car, or a refrigerator.

So, that is the main issue. If you except that premise, the premise that the web is the future, then I can't help but recommend you learn technologies that are fundamental to the future of the web: the technologies that are part of almost any web application. Those technologies are: HTML, CSS, JavaScript, and SQL. XML is good too.

The problem here is that it is difficult to start in the web domain, because in order to really create anything of value, you have to learn more than one technology. HTML by itself is just a flat web page. To be awesome you have to create that HTML dynamically and in order to do that you have to learn a lower level language like .NET, PHP, Java, or an opinionated platform like Ruby on Rails, or mine: Qrimp.

Then, to use whatever programming language, or platform you choose, you also need to power it with a database, so you have to learn SQL. Then you need to make that web page do cool things in the browser, so you have to learn JavaScript.

So I would recommend, if you are going to start somewhere to program choose either SQL or JavaScript. You are going to need those, regardless of whether you ultimately go with Ruby on Rails, Qrimp, PHP, .NET or J2EE.

So, to narrow it down even more, go with JavaScript. It's a lot like Java, which is a lot like C# (.NET). Reasoning: Keep your doors open. Start with the broadest technology that can be applicable in the most places, then narrow yourself down toward rock-stardom in your niche.

That being said, SQL is part of almost any information system, even outside the web domain. It's also one of the most difficult to wrap your mind around, so go there. You can actually create HTML with SQL if you want to. Most veterans don't recommend it because you are mixing the presentation layer and the data layer, but the point remains...

If you look at this breakdown: http://demo.qrimp.com/TechJobsCharts You'll see that the most requested skill set among technology jobs are HTML and SQL -- for good reason -- the reasons I listed above.

> to narrow it down even more, go with JavaScript. It's a lot like Java, which is a lot like C#

You are high as a kite.

Wow, well that was a great rebuttal. Perhaps you should review logical fallacies. If you'd like to disagree with what I say, attack what I say, not me.
Databases and SQL, everyone developer needs to know about them. They are easy to learn, incredibly ubiquitous and actually quite fun to work with. Have them start out simple by downloading MySQL and reading, say, <a href="http://www.w3schools.com/>W3 Schools tutorials</a>.

Regular expressions. Very useful no matter which area (desktop, web, mobile) you specialize in.

HCI, usability, interaction design. They should atleast know enough about usability and design to appreciate its importance and avoid The Usual Mistakes (TM).

Using and administering web server software. Learn about Apache and the most common modules (e.g. mod_rewrite) because the odds are pretty high that you'll have to set up a web server in the future.

I was thinking about this recently, and wondering if my own experiences are seriously biasing me, but Ruby On Rails does not seem that hard to learn, and is fairly well structured. You have to learn the parts of Ruby that are used for Rails. You don't need to know SQL to start off, CSS and html are pretty straightforward, depending on the website, learning and coding JavaScript could be the hardest part. There is a job market where you can work for a company (both large and small) or try to freelance. Maybe the same is true for, say, Django or some other web frameworks?
When I retooled myself from a physics dropout to a programmer (back in the 80s) the most valuable single thing I did was to work through SICP, doing most of the exercises plus little projects sparked off it. (I already had years of hobby programming experience, though; and I'd hope there's a better most valuable thing now, 20 years later.)
One decent way is to learn the software technologies and tools used in their particular domains. There's usually some set of fairly standard tools and plenty of self-taught experts to provide guidance. The other path is the more general - 'learning to program a computer' which these days really means web programming.

When the typical interaction with a personal computer was picking menu items from a screenful of text, you learned BASIC and that, while limited, gave you some idea of what programming was about.

Now the typical interaction is with a web page so arguably learning to program is learning to write web apps. The BASIC equivalent there is perhaps a page-embedded language like PHP. It's simple, direct, is an actual marketable skill and would introduce a beginner to a lot of the necessary details without much digression into more convoluted concepts (OO or functional programming, 'frameworks', etc, etc). Armed with the foundations, one can then branch out to things sexier/higher paying/useless - say, Ruby/Java/Arc.

A dash of Linux SysAdmin, a hint of bash, taken with a large glass of Perl. (Python seems to be the favoured Perl replacement here on HN)

It is amazing what you can accomplish by just learning those first.

You will have tasks (mostly sysadmin) straight away and build your programming from there.

I have always thought that getting familiar with a command line is a good way to think of programming for people that are familiar with computers, but not with software development. If they can start with some basic things (moving one file from one folder to another) and then start to get the concept of chaining commands together via scripting (moving multiple files to multiple destinations depending on the name) they will get a grasp of the simple concepts because they will know what they want their output to be. This sort of learning can take place in a matter of days and then I would recommend going to a language with an interactive shell (ruby, python, etc...).

From there, I find that short exercises are helpful. If they enjoy math based problems, I cannot recommend project euler enough. Otherwise, if they can relate their programming work back to their specific fields(ie, writing up an analysis of unemployment data or digging into gene sequencing), they will see it in a different, more applicable light.

I am biased being in the industry, but anyone with a good working knowing of a LAMP stack (know how to set up all components with default settings, understands the basic of SQL queries, can write a cgi script to fetch data from the database) can get into an entry level job with enough intelligence.

There is often a good leverage mechanism if you can do more than one thing well.

For instance, has the biology guy a suitable background for bioinformatics?

Tell them to start from their domain. Find a simple problem that could be solved using a command-line utility (ex: bioinformatics tools). Pick a scripting language (Python, Ruby, Perl - any big one will do since they don't have deep coding knowledge yet). Read an intro book, tutorials and create the command-line tool. If they found the language intuitive to them, great, otherwise try a different language. Then, incorporate storage using a simple in-memory or local database like BerkeleyDB or SQLite - the key is to focus on the SQL rather than db admin. Then, consider how you might create a web application for this tool (sure, it could be a stupid example of a webapp, but again the goal is keeping things simple). Maybe, a mobile app?

Hope the pattern is clear here. Tackle each bit as simply as possible to quickly build a wide range of skills and also find out where their interests lie. If something is especially interesting, go deeper.

Tell them to use the python plugin to SPSS to analyze things they already know. Use it to learn to do things like pull data off websites, etc.

(SPSS is a statistical package used highly in economics and biological sciences)

Try and learn the basics of good software design. These inlcude and not limited to: Design patterns, OO concepts, separation of concerns, testing to name a few.

In addition, it a good idea to havea clear understanding of different software methodologies (waterfall vs agile)

The programming laguage is important but at the end of the day its just a tool. Good design in software is what serparates great developers from the rest of the pack, meaning they have less stress, go home on time and generally always have good paying work :)