Was it:
1. Formal CS or Math education alongside or later on?
2. Pure grit and consistency in completing stuff you started
3. Working in real projects at industry
4. Something else entirely
Even people who went to a university only learned from the work they did. Most of what they learned wasn't on the syllabus. So, treat everything you do as a thing you can learn from. In any textbook you pick up, do all the exercises.
The main thing I learned in engineering school and used after was that not knowing how to do a thing did not mean I could not do it.
If you have to do a thing again, do it better than last time. Maybe the result could be better, or you could get there with less wasted time. Always devote some attention to how you could be better than you are.
If my first job had been at a larger company, filled with meetings and processes, I never would have built up strong confidence writing code, coming up with solutions and building things.
2. Starting out 20+ years ago, when Googling the answer wasn't possible also played a huge part. Coupled with a 1 above, it meant that the only way to solve a problem or to work out how to do something was to work through it over hours and days myself.
My early solutions to unusual problems or tech shortcomings were not always ideal, but they always worked.
Both of these helped build up confidence in my own abilities, a knowledge that there's no problem I couldn't solve, and the certainty that I was fully capable of building whatever I wanted or needed to build.
2. I built a lot of little projects, but most not to "completion". I did take 3 freelance projects for way too little money (don't recommend undercharging), and those did get to a "complete" stage.
Eventually I got a job, at which point there stops being a difference between "self-taught" or "cs grad" because an engineer is always learning / teaching themselves at work. Most of what a web dev does day to day has little to do with the topics taught in a traditional CS major. Once i was working in the industry, I used work as a chance to keep growing and adding to my toolbox. This is not something everybody does.
I used to have a sense of inferiority to CS grads, but I actually think being self-taught prepared me well for the day-to-day job of a developer.
I am self taught, then went to a boot camp and now work at a FAANG. Things that helped:
1) Making challenging projects.
2) Spending lots of time reading CS books. Ended up writing https://thecomputersciencebook.com.
3) “Obsessive curiosity”.
4) Going to a top university (for non-CS).
5) Looking like a stereotypical programmer.
A solo public hobby project meant that I landed up having a kind of “portfolio” for my first actual software development job.
I was also lucky that the interviewers were cognisant of my background and the questions focused on asking me to explain my technical decisions and how I solved problems. They were essentially gauging my general software development aptitude and potential.
For the job I landed I had to learn C# (had only done PHP, ASP classic and JavaScript before), but I picked it up pretty quickly.
The other thing I realised after having the job for a while was that the fact I had seen the hobby project through to actually releasing something pretty polished was far more significant an achievement than I originally gave myself credit for as many supposedly “professional” developers haven’t achieved this.
Overall, a good bit of luck, but I was able to capitalise well on it due my being a bit of a “natural” when it comes to software development.
1. The most useful stuff I learned in school was concurrency related, things like mutex or mapreduce. I may not have looked into those skills on my own
2. I don’t do that. If I start a passion project, most of the time it either turns into a tiny Proof of concept, or I learn a lesson and quit working on it. I don’t regret that at all
3. I had a sales engineer style role as my first job- it was great to get exposure to how a variety of companies run things and I still reference that experience all the time. Now working as a developer- you learn a lot more about the trade offs of various decisions when you’ve got to maintain the thing later on, so that’s been really valuable as well
Also as another poster mentioned, starting off at a startup was basically steroids from a "practical knowledge" perspective. I got my first job as a self-taught rails dev with 1 personal site in my portfolio, and left 4 years later with experience in:
- native mobile dev (both ios and android)
- infrastructure management (chef, ansible, vagrant)
- server administration on both AWS and colo setups
- debugging + fixing performance/scaling issues in production apps
- Miscellaneous knowledge in PHP, React, sinatra, ruby in general
Most of those things I was introduced to in some capacity in the first 2 years honestly. Now that I've had the opportunity to go to several other companies, its clear that my willingness to get into unknown technology and figure things out the same way I was forced to at the startup is probably the biggest "super power" I have now. People in general really prefer to stay in their own lane tech wise I've found.
I worked through Columbia doing user support for the university's Unix systems group. I got a job on Wall Street like many classmates, but for which the hiring person (an equity analyst covering software companies) was specifically looking for a CS major; I was able to demonstrate that I had the equivalent background thereof.
I have been successful with computers because I enjoy working with them. I enjoy computers because it's a hobby, albeit one that has affected my entire working life. I suspect that I would not enjoy computers as much were it actually my job. Since it isn't, I have the freedom of being able to (for example) write Elisp[1] to improve VM, the Emacs-based email client I've used for almost three decades. While I may contribute my code back to the VM project someday, meanwhile I report to no one and have no deadlines other than my own. That's freedom.
[1] I well remember the epiphany the day in Logo class I realized what recursion is. I still feel like giggling when I find an Elisp task for which recursion is an effective solution.
#2 and #3 together are what I credit my success to. Showing authentic passion during interviews is also a hard requirement, as well as having good values that successful hard working people tend to value. For example happily and confidently admitting when you don’t know something. Also having the integrity and self esteem to admire and show open respect for colleagues who know more than me - ESPECIALLY if I notice myself feeling insecure towards the person for whatever reason(like we’re hired at the same with same title but they clearly are ahead of me). So far my 2 most valuable mentors were initially colleagues who made me feel insecure About my skills but, I literally locked my kicking and screaming ego in the closet while proceeding to befriend and become vulnerable with them to the point they adored showing and teaching me stuff. Advice for this insecurity: learn something from these people then directly incorporate it into your work and proudly give them credit for it. Poof, you gain some of what they have that you didn’t and your crying ego in the closet cant say shit now can it hahaha.
Above all else, I give myself credit for always taking interviews even though I knew I was probably out of my league and terrified - because it wasn’t the job I was after but rather the confidence I imagined I could have for the next one. If you can’t be confident and charismatic in interviews then i don’t see how you can het hired anywhere for anything that matters to you.
I started teaching myself programming in my teens - using books from the school library, and a copy of Turbo Pascal which I pirated off school computers.
> It was personal interest and pure fascination with algorithms, that got me started.
I remember getting a real kick out of understanding new things. Like when recursion first clicked for me... that was a great moment. I felt amazing.
I later went to university, but never finished my computer science studies. They never felt amazing, never provided that "it clicked" moment of understanding - but were full of tedious chores. I had to do side jobs for financial reasons, and I learned soooo much more on these jobs than I ever learned from lectures. So eventually side jobs turned into full-time employment and I just stopped going to lectures.
> It was working on real projects that made me accumulate the knowledge and experience that defines my pay grade today.
But it surely did require some grit and doggedness at several points along the journey to stick with it... and the reason for me personally sticking it out has probably less to do with determination, than it has to do with a slight aversion to changing workplaces because of social awkwardness... ^_^'
So, yeah. Many factors playing into this.
Because I did these things mostly for myself, the span of problem domains is big, I did backend web stuff, frontend stuff, CLI tools system daemons, embedded things, game-related things, audio-related things etc. This breadth of topics helps tackling anything my current employer throws at me (which is mostly also interesting problems).
This is success to me: I do what I like to do and am able to do it well enough to be happy with the results and I am fast compared to others while doing it.
E.g. last week I was asked if I could do a local groupchat webservice for the wifi of a theatre piece (so visitors can interact with the actors on stage, without having to install some kind of internet bound app). Four hours later the working prototype including nice handwritten CSS and realtime message-passing was done. Feels good.
Also ADHD and being self taught means I have my own, weird, probably not very efficient way of learning things that involves a lot of skimming metric tons of information. Ingesting new information is how I keep my brain stimulated. Honestly, I never understood why often learning is an effort separate from the act of using. Why people tend to go on a course, absorb information, then just later use it. They should be interwoven, learn by doing and do by learning.
Also my parents couldn't afford to send me to a real university (I wanted to go to MIT as a kid and I was in the middle of nowhere in Southern Europe), so there's that.
The only reason I got started with *nix is because when I was about 10 I saw some network news piece on this wacky Finnish guy who was making his own version of Windows with his friends because he thought Bill Gates, who was in charge of Windows, was lame (I'm sure it said something else, but this is what my child brain got from it). Basically I didn't get into Linux and the BSDs because I was a Unix fan (how could I be, if my only computing experience until that point was Apple iis at school and a few months of having our first PC running Windows 98?) but because I was drawn to the radical politics (though I definitely wouldn't have phrased it this way) of making your own free thing to compete with the richest guy in the world's expensive thing. When I learned that Id had released the source code to Quake under an open source license (the same one as Linux even!) too, I begged my parents for a book about C so I could understand it (though I never succeeded).
From them on, I was a computer hobbyist and free software ideologue and consequently became quite fluent in shell, Perl, and PHP, but I never even contemplated doing any of that as a career until I was laid off from work in another field and a few (jobless) weeks later saw a billboard advertising Linux admin jobs. I called and they hired me, and I accepted gladly because I was newly-married and broke (and my wife wasn't working at the time either).
My career progression since then has been a little more deliberate, but that initial spark was really because my pre-adolescent brain liked the idea of getting one over on Bill Gates.
In short, I was lucky to be interested in this soon-to-be-lucrative thing as a child, so that when I really needed a job I could "fall back" to it.
Along the way, I managed to study most of a CS curriculum, but I didn't have that as a goal.
I would have no career without Anki. Every time I pull out some obscure technique or command and make peoples' jaws drop, I have Anki to thank for that. From VIM commands to remembering which PHP functions are nounverb() or verbnoun() or noun_verb() verb_noun() to bash tricks to Python libraries to web tools to curl options to network terms, every day I pull out something to make myself more valuable to my employer. And other employees know they can usually find their answers with me. And I really so smart and experienced? No more than any of the others, really. But with Anki every single small trick and technique is remembered and ready for use.
I’m a knowledge sponge, and by nature have a fleeting attention (ADHD recently diagnosed), so even though I was not able to keep at something very long, I at least was able to learn a lot of useful thing fast.
Now I’m trying to dive deeper in my interest - programming is a tool for me, not an end in itself, so I’ve switched to other interest. Still using with electronic component :)
In short not moving on before mastery, then moving on after mastery.
[1] I think this analogy is fitting because the drive that makes write five versions of a three line function feels similar to the drive that makes me choose whatever path I haven't walked down before when going to some errand or another.
Luck for having computers around all the time and the privilege of being able to have worked on them and spent lots of time with them growing up. This gave me a really big head start. Luck also for turning some smaller gigs into much larger ones, because the opportunity is not something anyone can really replicate. Most companies explicitly shut off upward movement especially for lower stage positions. I ended up at the right place at the right time with the right skills at a role ancillary to good software engineers. From an ad for a part time low level position off of craigslist.
Connections because I had a friend who had the patience to show me what to do and guide me on what to focus on. It wasn’t perfect but it helped a lot. Also got me in the door at the first job by recommending me as someone who learned fast.
Determination in forcing myself to do the practice and try to learn and build things that got me into the first gig.
After even 6 months of the first job everything became easier, companies would reach out to ME, I’d get incredible amounts of traction and my salary kept going up. Just getting the foot in the door matter immensely.
Also there’s plenty more in the luck column, mostly around privilege.
I’ve had many many friends who were capable but could not replicate it. I feel fortunate for the opportunities I was given early on. I wish there were more opportunities for capable and smart people. We as an industry treat junior engineers as if they have a disease.
Programming (logic) is a language where everyone is on a level playing field - or that's how I perceived it at the time; any funny language, dialect or outer appearance is of little to no importance. Lastly, it has the potential to do enormous amounts of work, automatically.
I definitely feel like becoming ‘self-taught’ today, on the entire stack down to at least the operating system level would be very, very hard. There are far too many levels of abstraction to drill through.
If I had to do it today, the only reasonable path is to start at the bottom and work your way up. Starting with something like Python or Ruby is not the way, regardless of the quick wins early on.
Being exposed to that project and an architect willing to explain not just what but why, really put me in the right mindset early on. I learned principles instead of technologies.
1) No it wasnt CS or math education. I was trained as an EE and was expected to program in C and Assembly for my assignments. We were just expected to pick it up without much formal help (circa 1999).
2) I feel this aspect is required for any endeavor.
3) This should be true in theory, but very much depends on your team and size of the company. If you work for a small sized company, you can create a whole system and learn a lot. Working for a BiG Co, you'll just do a tiny fraction of the whole system and your learning may be limited.
4) Curiosity. When I first learnt programming, I remember using programming to "verify" what I was learning in EE classes. I realize now it was silly to "verify" if Newtons method or Fourier Transforms "work", but at the time it tremendously aided my understanding of translating textbook concepts into code. This aspect has stuck with me. Later when I moved to Data Science, I returned frequently to this method of reproducing basics using my own code. I feel it has indeed made me more effective in my job.
6. Curiosity
7. Trying to be responsible (you would not believe how many people just dont f'ing care, if you're not one of them this already puts you ahead)
Non-reasons: Formal CS - yeah, got some (msc-level edu), learned most of my useful CS before/outside that tbh (with the only exception being database logic and loads & loads of sql). That's not to say Computer Science is not important - it is - but formal CS isn't)
I've been driven by enjoyment of programming, financial need, and, I've been thinking lately, the sense that programming was "my thing" - something no-one told me to do, understood, or even really wanted me to do. Computers were like an alien landing to my hippie/artist parents.
Never took a single programming or CS class, I was interested in various liberal arts type subjects throughout college. I don't know much about computer science, algorithms, etc. But I'm good at what I do and have a solid, stable career working for cutting edge companies.
My dad still doesn't get it, has no interest. Which is annoying but also kind of works for me. Still a teen rebel for being a programmer.
I love getting it done and getting it done right and staying up on the latest. A day where I write good code creates a nice calm feeling I can access as I drift off to sleep. It's been a great career so far and I guess I'll be programming on the day I die. It's fun, why not.
Every role since then has involved some sort of amusing story or another in regards to interview timing, people looking for staff at the right time, connections, etc.
But I'd say aside from the obvious luck component, a certain degree of interest in the projects I chose helped the most, since it's very difficult to stay invested in a project when you don't care much about what you're making and you're coming up agaist hurdles you didn't expect.
The first allows me to read book, without having to follow examples or have the real things before me. It was handy because most of the time I did not have access to a good computer or to the internet.
The second allows me to jump around. I could start with a book in security, hit a wall, the start a book on networking, then understand what was blocking me, and then read about operating systems and really understand another part of the first book. My knowledge is the sum of fragmented parts from all the books I’ve read (a lot). I do not have direct link to it, but a word or anything else can bring the relevant context. I use that a lot in exams where the question itself will bring back the answer to memory, or at least an hint.
All of these allows me to do non-linear learning, and inside my own head. After I can do a short session of practice, cementing things I deem interesting.
Realistically, both are involved. Being able to get by working a job (or two) that still allows you to have enough time and energy to study and learn outside of work. Lucking out with the job openings when you're searching — you can increase your luck surface area, but you still need fortunate timing. Networking with alums from your school. Even having been to college at all. Already living in an area with tech jobs. Knowing _anyone_ in the industry already.
There was an absolute _ton_ of hard work involved for my journey through, but there was luck and privilege involved as well. I think these aspects are important to include.
I am always genuinely curious, I always want to understand how a particular idea, bit of code, software, tool or algorithm works. I am always trying to get better ideas to solve old problems and always trying to solve new problems.
But 1, 2 and 3 are important. With just 4. I would have ended up as an enthusiastic but mediocre code monkey.
1. made me think in terms of Computer Science not mere coding. Also, besides learning a lot of things I wouldn't have tackled on my own. Also it helped me make a lot of conexions between different ideas. It helped me to also learn how to effectively learn. And it made me lots of useful connections from faculty staff also working in the industry to my peers who got employed in various areas.
3. helped me talk the same language with my potential employers and solve the problems in a way my employers expect me to solve.
2. is obvious, consistency and determination is crucial for any endeavor.
After learning the basics of how to use desktop PC on a Commodore 64 I moved to a Mac Plus and then bought my 1st new computer, a Mac PowerPC 6100. I used the "Apple Media Tool" to create a CD-ROM running in an "Interactive Kiosk" I put in hotels that had ads for local businesses. Mostly restaurants and tourist attractions.
The Apple Media Tool had a GUI to do most of the work, but it also had a feature that let you edit the code it produced and not long after the internet took off and I started making websites for businesses. I started off using Adobe Pagemill and that too let you view and edit the html code. From there I started hacking Perl CGI scripts and then writing my own using CGI.pm mostly.
I avoided Javascript for the first few years after it came on the scene but started using "Prototype.js" shortly after it came out. Not long after that I rewrote most of the server side code for an app I made with Javascript and jQuery and that's still what I use most.
I still use Perl on the server side but for the most part my apps run in the web browser. I use CouchDB or the web browser's IndexedDB for the back end. Never did really like SQL for web apps but CouchDB/PouchDB.js has been easy for me to work with.
So for the most part I have depended on the kindness of others for the code I use most, and have only written code on an as needed basis, or just to play around and experiment.
I really like the tools I use to make web apps. I've been able to hand off the hard parts to them and focus on the features I want to create. And if something comes out that's better it's generally easy to implement it. The move from Prototype to jQuery is an example.
I spent some time going over frameworks at https://todomvc.com/ and when I'd went over those I was interested in I decided to keep doing things my way.
Hard work.
Many many many uncountable hours programming.
Deep curiosity about every level of computing.
Coding coding coding.
Learning reading researching.
Relentless willingness to grind on problems until solved.
A deliberate decision to focus on learning the set of technologies that would allow me to build every part of an application. React, Python, typescript, Postgres, Linux, AWS.
What drove my "success" was a passion and curiosity. What I could do, tinker, and learn in the programming world was endless. I lived,breath, and sh!t JAVA, C++, VB, COBOL, js, HTML, etc, etc for about five years. My first year I camped in my cube, going back to my apt only for shower, and I wasn't even paid well for it. I made less than 30K/year.
Now I'm a SE in a DevOps/EDR company.I still code on the side for fun, but it's not a major focus of my job.
Another factor is having a family computer around when growing up, I learned to program for fun. I remember working on a BBS (bulletin-board system) code base written in Turbo Pascal, back in the days before the web, when I was around ten or so. https://en.wikipedia.org/wiki/WWIV
Interesting how one feedback loop can guide you through your whole life
It's not so much about grit and determination or whatever these days. It's that there are smart and kind people willing to help each other out online, for free. It takes a community, not individual superpowers.
You don't have to be very smart or driven to be a developer. You just have to be willing to admit ignorance and ask for help.
The reason is curiosity and grit. The more you learn the better mental models you have, the better you can do analysis and extrapolate. As for grit, I am looking to find my ceiling.
I have met devs without any curiosity and … it shows.
2. Grit and consistency is needed when working on difficult projects i.e. the ones you learn the most from.
3. Usually difficult project are difficult because there are several constraints (e.g. business, tech, domain). So my first years in the industry helped me a lot.
An important factor that allows all of the above is having fun and being passionate about your work.
I have tried instructing my brother and my ex-gf to learn in the same way I did, and they both failed, and both because they needed to learn to program, but had not real interest in it. They are both equally smart, so it has little to do with intellect.
So my answer is
Doing programming related stuff almost everyday (excluding job)
After a certain amount of time (years), I could troubleshoot any bug. No need to reach out to others to solve bugs. I will always find a way.
Using GNU/Linux as daily driver. Helps with dev-ops enormously.
Lastly linked to the above, learning the full-stack.
Am I a success.... na. But I consider myself a success in terms of being self-taught.
The primary reason behind me being where I am is probably curiosity.
Did all of that. What was more is not being afraid of failure and new challenges.
Ive been constantly exposing myself to different and harder topics.
2. Working in real projects in the industry, while continuing to learn via hobby projects on the side.
3. Good, picky code reviewers who taught me to dig into the internals of how things work and question + test my assumptions.
4. Luck.
Later i joined a USA based startup really large project. This is where i learned how to manage large SaaS apps and how to manage complexity.
Since then i have been only building SaaS products and i love it. Currently i am leading the development of microservices based system based on GraphQL and everything is running k8. i have worked on every part of that system.
I think starting early helped me a lot :)
- I eventually discovered QBASIC.EXE and it had really good copy-paste examples which got me into programming.
16-years-experienced, self taught developer/designer/engineer here — currently working with international enterprise/corporate customers as a professional services consultant for a large cloud services provider.
1. I don’t have a formal background in CS, but I have had to learn the industry-standard ways of solving common problems and continuously assessing order of complexity for both systems and code along the way.
2. I started with nothing but a design background and skillset, and I had to learn to supplement it with technical skills at each stage.
3. I really feel like my “success” (which is completely relative btw) is due in part to the time during which I picked up the core development skillset. Back in the early 2000’s there were no mentors around. You couldn’t just stick an evil error message into Google and expect to get the answer to your issue in 20-30 seconds. There was no Stack Overflow (and for a good while, still wouldn’t help).
Sometimes you had to monkey patch the problem. Other times you had to find an alternative route. Sometimes you’d realize that what you faced was a real limitation of the tech you were working with and you’d have to either devote the time to fixing it or give up and switch to something else completely. And yes, that was before you could submit a PR on the Github repo with your patch, so the next release would almost always break your “fixes”.
4. Multi-disciplinary interests and skillset. Having a highly-fungible skillset and being really interested and fascinated about the world around me has contributed immensely to both the technical as well as the professional side of my career and growth. It helps me earn trust quickly with customers, but also provides deep insight when attempting to model a real-world, manual process into a machine — which, in my experience is about 95% of the reason people pay us to do this job.
One of my side projects even got venture funding (and not in 2021 when things were overheated -- back in 2003).
Fail often. Understand why you failed.
Don’t fail in the same way doing the same thing.
Combine your understanding of all the ways something (or many things) can have failures into success.
Ask to understand
——
Can expand on above if desired
It is a good idea to get a formal credential, it makes it easier for HR to fiend peace with a resume.
4. love for technology, everything else was a side effect. To this day it still feels magical with many layers to uncover and learn.
- Side projects
- Free time to spare on coding
- Landing a real programming job
fuckton of luck
I mastered functional and then object-orientated self-taught programming as a teenager in high school, and ended up employed at 18 with a graduate level job at a well-respected technical employer.
I was able to do the job in front of me, which is why they employed me without a degree, but working with incredibly experienced engineers who had previously worked at Apple and IBM I soon realized that was a vast difference to how they approached problem solving, system design and design patterns. We were building the content management system of a large news organization so it was a significant system.
I think my lack of design patterns learning was probably the most profound indicator of difficulty. I had muddled through learning programming from books and looking at mostly crappy open source code whereas my peers had learned academic CS at MIT or Cal. That was clearly a significant delta between my ability and their ability, and I realized that ultimately, I would never be able to compete with them or their wider academic peers in the industry without that level of training.
For various reasons if I had gone to university I would I have attended the equivalent of a community college and therefore the quality of my CS wouldn't have been particularly good anyway. I just never had the opportunity to attend a prestigious university.
15 years later, working at Uber around 2014, I worked with some of the best engineers I've ever met and saw some really significant work done. I already knew that I had made the right decision when I pivoted in the mid 2000s, but my experience with Uber really confirmed it.
I know this Ask HN asked about successes but actually I think my career was successful because I had a good enough understanding from being self-taught while making sure I changed track to one that I could be successful in.
I'm not sure anyone would hire an 18-year-old software engineer without a degree in the current era and I was lucky because the internet was just in its early formational years in 2000, when I entered the job market. I don't think that's possible now.
My advice for self-taught programmers would be to consider how you approach the gap in design patterns and learning by osmosis from those knowing best practice that your peers who have academic CS training.
I think you also have to consider how you will compete with those who not just have a CS degree but attended a top tier university. Maybe you don't want to work for a Google or Apple, and that's fine, but I think it's important to know what your goals are and whether a lack of formal education will enable you to get there.
For me, I worry that self-taught programmers become about the same as those who went through one of these boot camps- able to work on internal tools or lighter workloads but really reach a ceiling of their ability in the mid-career unless they pivot to something else like eng management, product management, etc
As a former hiring manager at one of these companies, despite being self-taught myself, I'm not sure I would hire someone with the same lack of academic background I had, unfortunately.