Ask HN: How to Transition into Programming

As a self-taught developer here is how I did it.<p>I taught myself XML Schema a year before my employer at the time involuntarily forced me into programming. From XML Schema I learned a deep appreciation for language modeling, data structures, and relationships as trees.<p>When I was forced to program in JavaScript, my first language, the first thing I learned was to become very familiar with the DOM. The DOM is the backbone of everything frontend web and with that confidence you can do absolutely anything faster, both execution speed and development time, than most professionals with large frameworks. Understanding the document&#x2F;page is a data structure of objects each with known relational paths to other nodes is a huge performance capability most people will never learn.<p>Then I really started to learn the actual language. Functions are everything. They are first class citizens which means they can be used and placed anywhere you can use and place a primitive, which is super expressive and portable. I also learned the advantages of the lexical scope model.<p>I learned early on that good software is explicit, portable, and highly predictable. If you have to guess at what’s happening when reading the code the code is poorly written. Code has flow control and the more immediately you, as a human, can read and trace that flow control the more durable your software is against defects and much faster to patch defects.<p>In my experience as a developer the biggest failure I see other developers make is that they never learn about automation. They expect some set of tools or memorized conventions to solve that for them. When the developer side of a software product is automated documentation is more available and up to date, performance is accounted for early on, regression analysis is baked in to warn you at the earliest, and so on.<p>The last major thing I learned as a developer was to measure things. Developers tend to guess at performance and tend to guess wrong by several orders of magnitude more than 80% of the time. Performance is either measured in duration (time to complete an operation) or frequency (operations per second). High performance is a force multiplier. Faster software features mean faster testing and faster analysis both manual and automated. Frequently waiting on software and page loading induces mental fatigue.<p>Honestly, not everyone can be good at software, but everyone can learn to write bad software. It’s the difference between administration and problem solving. To be good you need to have a passion for solving problems and improving things. It’s more than putting Lego blocks together. Anybody can snap some blocks together. To be good is more like determining what you need to do to take a car and cut the price in half while simultaneously making it faster than the competition.<p>If you do want to be good you need to innovate outside of work. If you are waiting for the job to tell you what to write you will be just as average as everyone else and lack the criticality to make more informed decisions about why current practices are crappy. That’s why measuring things is important.

It&#x27;s a tricky time to be a junior. The market was competitive already, but with economic turmoil many orgs are pausing hiring, especially at the lower end.<p>My suggestion would be to focus on just _programming_ at first and then finding the job second. Try and build some software for your personal productivity. Try and script parts of your day job to both practice the tech and get benefits out of doing so.<p>When you apply for that first technical job it will be I valuable to show that you have written programs, reflected on their shortcomings, and learned more about designing applications. I am a big believer that every aspiring programmer needs to _just. write. programs_.<p>To answer your specifics<p>1. Has anyone made a similar transition?<p>Yes - I started my career in UX &#x2F; product but then shifted in web development. This was about 2013 or so. It was a different environment... in some ways easier to find entry level roles, but in other ways harder because there was little support for non-CS grads. You had to be entirely self taught, really, and still go through a lot of DS&amp;A style interviews aimed at comsci grads.<p>Because of my background the path of least resistance was frontend development - this has been enjoyable but sometimes I regret not having a CS degree, and wonder what else my career might have involved if I&#x27;d had that leg-up.<p>2. What resources are there to &quot;deeply understand&quot; programming?<p>The internet, your time and your brain. This is a job about research and problem-solving and that applies to the problem of learning tech as well. Some people find the self-starting aspect intimidating but in other ways it&#x27;s freeing: you can do this all by yourself, you just have to keep practicing and keep making time to learn.<p>3. Which companies are most friendly to someone like me?<p>Startups might like your product-y focus, large orgs may have dedicated junior programs. But the latter might be on pause for a little while.<p>4. How realistic is it to get into FAANG with my background?<p>It will depend a lot on where you are. It tends to be much easier in the US, especially coastal US. In Europe their operations are smaller.<p>Personally, I count myself as a pretty good programmer, but I don&#x27;t think I feel up to the investment of revising DS&amp;A for a FAANG interview. It seems like a big commitment and I have so many in my life as a thirtysomething. It sounds like sour grapes, but I&#x27;m not sure I&#x27;d enjoy it anyway (an ex-Google manager told me I&#x27;d find their culture stifling). And I would rather spend the revision time on other pursuits (marathon running, writing, family).<p>---<p>Good luck!<p>Also, remember you can share projects for feedback on HN by titling your post &quot;Show HN:&quot; - this is for all levels, even beginners