Ask HN: any advice for someone changing career to become a software engineer?
One of my friends in his late-twenty has a technical master degree (not related to computer science) but he would like to change his career to become a software developer. He is not satisfied with his current job / working field and he is already learning HTML/CSS on his free time. A bunch of his friends are software engineers (me included).
I think it is possible for him to work hard and gain enough knowledge to find a job as a junior web developer in a few months (a year?) from now. But should he focus on JavaScript and single page applications? On a specific framework? Should he still learn a server site technology and if yes, which one?
I am a JavaScript developer so maybe I am seeing this whole story with blinders. What if learning iOS or Android would be a better use of his time in 2014? I may be wrong, but it looks like the market is looking for "native" mobile developers more than web developers.
What would you recommend to him?
48 comments
[ 3.3 ms ] story [ 52.9 ms ] threadIf he just wants to make more money but doesn't care much about programming/developing software, just tell him to go to one of those Rails/iOS/etc bootcamps for a month or two.
Whenever someone comes to me about getting into programming. I tell them they should think of an idea they think is awesome and start building it.
http://mattdeboard.net/2011/11/23/how-i-became-a-programmer/
There are a couple other entries there about this general topic.
Build stuff, a lot of stuff. Most of it will be bad, but it will start to get better, AND you will start to develop speed in the form of mental patterns for getting things done. Some of those patterns will eventually change as your mentality shifts from "just getting things done" to "getting things done well" to other concerns. Software is largely a set of tradeoffs.
I think getting things done is understated because it also means learning to deal with ambiguity in features/ideas/specifications/product. This can cause paralysis for some.
Once you get good at programming it's fairly easy to drop into other languages if you need to.
Having an end goal is exceptionally powerful. Spec out your idea fully and then try to make it real.
This may sound boring and tedious, but if you don't know how GET, POST, PUT, DELETE etc. work then it won't do you any good trying to wrap your head around frameworks.
Learn some of the common responses and what they mean and are typically used for (200 is ok, 302 is a redirect, etc).
REST-style frameworks are just abstractions on this protocol, and a good understanding of it will help to make sense of why web dev frameworks are built the way they are.
You told he "has a technical master degree". and I would advise to focus coding goals towards solving problems within his domain. He might be a bad coder, but he can certainly compete to an average coder, who has no domain knowledge.
I really need to know if I just need to suck it up and do that for a few years and then try to change it up or keep learning and try to follow my passions now.
I think the worst part for me is that I know how much I don't know, so I have no confidence in my ability. That said, I've always received compliments from other people about my code. It's a big barrier to overcome.
Exactly.
Every field is bound to have some common problem which is dying for an app to mobilize it, a site to collect and correlate it, some code to automate it or a framework to organize it.
Identify a problem in the native domain then figure out to leverage code to solve it.
This is exactly the sort of transition I'm eyeing, but I'm looking at it from the perspective of systems/operational tech rather than something entirely outside.
At first sight, we can not see one but he will keep trying to find one because it is definitely helping to work on a project that could help you in your current job.
That said, I tend to agree with gofer's comment about how it could not evolve into a position of developer in his current field. There are definitely "IT people (developers included)" and "domain experts". Maybe mentalities could be changes…
Goddamn lack of a college degree holds me back over and over.
1) Grit - the ability the struggle through problems and dig through many rabbit holes/frustrations
2) Passion - true passion for technology and trends to keep up with latest frameworks/languages/etc and patterns- generally (but not necessarily) is the first step for grit
3) Problem Solving Frameworks - the ability to create frameworks for yourself to solve programming issues including debugging, asking questions, talking to a duck, etc.
Feel free to e-mail (in profile) me and I can set up an intro advice call with your friend.
http://www.businessinsider.com/software-developers-fear-age-...
At least for me, there has always been a strict firewall between "developers" and "domain experts". The roles are dictated by the degree you have.
Basically, as a "domain expert" you wind up doing tech support (i.e. help desk / call center / on-site training, etc) for whatever gets developed instead of actually gaining any software development experience.
Admittedly, my experience is entirely restricted to large corporate settings, so the situation is probably very different at smaller companies.
You don't want to use the right software language or framework with the wrong approach. You want to be able to reason clearly about the core problem and understand the tradeoffs of different classic solutions. Or invent a brand new approach. Or invent a framework or invent a language if necessary.
Consider this a plug for at least undergrad level education in CS. You can learn most of the rest of it on the job, but not computational thinking.
You absolutely do NOT need multiple years of CS undergrad to have a sense for scalability. If you open your mind, you will see that world history is chock full of systems that have scaled -- they just don't happen to be written in binary or backed by CS degrees. And I would say that these historical systems share more similarities than you would think with scalable computer systems.
In order to be good at this kind of thing, one just needs some sense for abstract thinking -- which countless non-programmers have, we are actually not unique in that regard -- and if you are adequately dedicated, a few weeks (or a few months at most) of study time to understand fundamental algos and data structures. After one has an understanding of it, it will certainly take more time to become practically comfortable using said concepts, but that's what entry level jobs are for.
They are not useless abstractions for people to write mathematical papers about. These ideas are what enable you to proceed deeper when your framework leaks and breaks.
Anyway we are probably in violent agreement.
The dirty secret is that most of the exciting dev work is done is small shops by guys that figure it out on SOF... and then fine tune it.
Let people say what they want about Xcode and Objective-C, but I prefer it over working with Javascript and one of 50 frameworks.
If you have any aptitude for this business at all, you ought to be able to pick up any language and API in a couple of weeks work, once you know your stuff. What's hard is having the discipline to get through the sloggy parts - fixing tricky bugs, adding features to your thing until it's actually useful. That's why it's best to start on building something that you can personally use. You'll have the motivation to finish that's hard to keep when you're learning something you have no use for.
If your current career involves doing anything on a computer that can be repetitive, start by automating that. Build a website or an app that does something you need. Keep working - keep adding features to whatever you build, as long as it makes sense.
If I'm doing the interview, I'd much rather hear about how you solved a real-world problem with your skills than how you spent X years learning Ruby or Java or Objective-C.