I tell those friends

- it's not for everyone, you sit for hours in front of a computer not socializing

- it can be a very rewarding career, there are many tracks one can go down

- it requires a mindset that learning never ends, many people have stopped learning, so restarting that process is difficult

- that switching careers typically takes full time effort to be successful.

- to checkout the Grasshopper app to get a taste of programming

- try an online course before spending significant money on a boot camp

- bootcamps are a better path than self teaching, but to be very careful when selecting, top ranked and widely know is the way to go

- sometimes it can be better to learn a little programming to automate processes in your current role, rather than switching careers to become a full time programmer

1. My number one suggestion - have intellectual curiosity to the point of obsession. You can succeed without this quality, but you won't be as forward looking and will be doing what is required by the task at hand.

2. Heathcare has been secretly booming for the last 10 years without very much attention at all. The convergence of regulation and technology leaves a _huge_ opening for innovation right now. Specifically, as of this year the patient will own their data and can use whatever application they choose to ingest and utilize that data. It's a big deal. I wish I was in a place where I could be part of the end-user experience.

> there are many tracks one can go down

I think this one is very important - both for the person giving and receiving advice. There are so many paths just for software development specifically. The paths absolutely endless. And that might be exciting or present opportunity. But it's also a responsibility of someone giving advice to make the person aware of the vastness but also to help them navigate it all.

Yes there are three or four major languages, but you could find yourself working in one of hundreds. There are many support technologies - front-end, back-end, api specific, frameworks, hosting, data storage and models.

And related to but not specifically software development, there is QA, devops, project management, and many other support fields that require an understanding of how software works.

> this year the patient will own their data and…

Anyone have a link?

Really, entering software isn't that bad. I didn't have any coding experience before college, and after my first year (which only entailed two software classes - I took a lot of humanities that year too), I had a job writing code for a research project. Thats a pretty quick path to employment - about 100 hours or less of training total*. I think any motivated person with a decent predisposition for math and logic could pick up the same skills in 6 months of effort, maybe even on nights and weekends.

I am not a super smart person either - I had an average talent and got average grades. However, the asset I do have is that I am OK with sucking and failing at something over and over again. I think this trait is more important than intellect.

Are you the kind of person that can bang their head against a problem for many days not quit? If so, you can be a software developer. Some natural intellect will help, but perseverance is likely more important. In fact, maybe being somewhat unintelligent is even better since you will be used to not succeeding at everything so easily.

*Caveat - it took me about 7 additional years to actually become good at writing code.

To provide more perspective - I went from not really coding to an internship offer from a big tech company in about 12 months, and I didn't even work particularly hard. I still have no idea how to code though

>Am I wrong? Is software really not that hard, and able to be learned later in life?

You are wrong. Software is a passion of yours and had been all of your life, but that's not the case for many or even most of the many millions of developers out there.

For them, it's just a job and it can be learned just like you learn any other job.

I studied history at university, did a lot of traveling after graduating, working casual jobs for years. I was 28 when I started work as a junior developer after spending a few months doing an evening course in the UK. (1998)

I chose programming as a profession not because of any passion for the subject (I had none), or experience working with computers as a teenager (I never had one). I chose it because even back then, in 1998, it was a lucrative profession, and one that I could learn 'on the job'.

Things were a lot different back then. On the job training was more of a thing and CS courses were not always packed to the gills at university.

You can be a great doctor without immersing yourself in medicine from a young age. You can learn to be a great vet, lawyer, school teacher, even writer. Writing code, building software - it's no different.

>What do you say to someone who wants to get into software development?

Tell them you need to put in the work, but the rewards are worth it. Tell them it's a varied field, as varied as medicine (where there are nurses, GPs, plastic surgeons and heart transplant surgeons). Tell them that even though they might make lots of money, that money alone won't make them happy and that the office politics is no better or worse than any other profession.

A few friends have asked me about this, idly wondering whether they should join a bootcamp or whatever. I enjoy teaching, and am quite good at it, so I give them an offer: a free 1-2 hour 1:1 introductory programming lesson. About half the people take me up on it and none of them have yet subsequently applied to a programming bootcamp. One person maintained a baseline interest and I occasionally give them more free lessons, which I find is a nice group virtual activity to maintain a long-distance friendship.

A lot of the time this voiced desire to get into software development is really approximately the same seriousness as a new year's resolution. Some flash of desire for self-improvement that quickly dies, before or occasionally after the first attempt. I also see something similar from software engineers who want to get into my subfield(s) - they'll ask very specific questions about which textbooks to buy, videos to watch, etc. for every tiny topic. I'll answer them, but have no real belief they'll achieve their goal. Often the goal is felt to be satiated upon spending money to order a textbook. I myself am not immune to this phenomenon, of course, as the hefty physics textbook sitting unread on my desk can attest.

Entertain their desires, encourage them, but give them opportunity to gracefully fail without destroying their savings and mental health by flaming out of a bootcamp.

What subfield would that be?

Formal methods and distributed systems. I'm also fairly knowledgeable about quantum computing.

There is nothing special about software development in terms of a career. You learn it like you learn anything else. Some people have a natural aptitude, some people will never get it, most are in the middle: capable of becoming competent developers.

I mean, 90% of development these days is knowing what parts to glue together and where to get the parts. You're converting business rules into code: for the most part, it's really not that hard.

Want to help your friends get into software and don't know what to say? Tell them to go for it. Let them decide if they like doing it.

> it's really not that hard

I think this is a myth that people who learned a long time ago and learned over a long time say. It is hard - there's a lot of complexity involved. It does a disservice to other software engineers.

Many things have difficulties and complexity. I would phrase it not as "software isn't hard" but that "it is no harder than many other things". This specific questioning is not often employed for many other equally complicated and difficult fields, which I think is a bit unfair and often acts as a gatekeeping mechanism that has led to diversity problems in the field.

> It does a disservice to other software engineers.

How does that phrasing affect any other engineers?

I highly disagree. Software engineering is hard, but out of all the engineering disciplines out there it is the easiest. That's why it's a very normal thing for software engineering to be learned in boot camp or without any assistance.

Most other engineering disciplines are much harder in the sense that the benefits are not immediately practical and the answers aren't as straightforward. Not many people are going to learn electromagnetic theory on their own.

Many software engineers think they're smart because software allows developers to hit all these epiphany points on a constant basis. You hit successes and you can learn convoluted concepts quickly because software presents it all to you in an idealized abstraction. It also quickly tells you whether your attempt at a solution was correct or wrong. It allows for quick learning. The reality is.. all of this happens because software tends to be easier.

Other forms of engineering don't provide you with that many euphoric highs when you learn a new concept or solve some problem because they are so few and far in between. This itself is an indicator that those other fields are punishingly hard.

Just to re-emphasize. I am not saying software is easy. Software is hard. But easier than most other forms of engineering.

That seems to be a different argument.

Also the products of bootcamps tend to be quite poor for the most part.

I remember helping a friend with his intro to CS homework in college. It was fizz-buzz type programming and extremely simple, but he could not understand what the code was doing or how to change it to make it work. And this friend is very smart and successful in his career.

Things that seem easy to people who already know how to program or who have the mind for it are very confusing to people just learning.

And for others it goes quite quickly! There is no doubt that programming can be helped with a natural aptitude and that it won't make sense to everyone no matter how smart they are, but that is true of many fields.

I'd also argue it's often a teaching problem. I'd highly recommend this essay that goes into the flaws in particular with introductory CS education:

https://felleisen.org/matthias/Thoughts/Developing_Developer...

Thanks for that link! That six-step design process appears to be a formalization of what I've learned to do subconsciously from years of experience. I've been struggling with mentoring junior colleagues wrt the software design process, and I'll be trying that six-step approach as part of my mentoring.

I recently put my wife through a programming videogame (exapunks). She gas a mechanical engineering degree. She has great memory, but she said the hardest part was holding 2 nested loops in her brain to foresee the execution.

That's when I remembered that way back I had similar problems. It takes time to develop that skill and the average person will struggle with that

Cool! My new year resolution is to not buy more games while I have other uncompleted or not started ones but I have bookmarked that game for when I start buying games again.

That's a great game. I feel like my skills improved a bit playing it.

Sometimes, if it’s a large and complex code base, the difficult part can be knowing where to glue parts together, and how it relates with the rest of the functionality. So even if one has the aptitude to learn programming well, both patience and some grit is good to have to make a good career of it.

1) Software development takes 2 weeks to be able to do, and 15 years to be good at

2) You're competing in a global heavily saturated market and need to find a way to stand out (all the qualifications, certifications, github repos, friends you can get to land the first proper position)

3) You're not special but you're not a failure either. Software dev is a rollercoaster of feeling like you're one or the other

4) Don't aim to be a software developer, aim to solve a problem you're interested in (software development for the sake of software development is terribly dull - 99% of the problems are boring - find the 1%)

5) Ignore the hype. You won't be a rockstar programmer, top 10 app store, bitcoin millionaire tomorrow because you bought that Python book

I spent a lot of time thinking about this over the years and I have a few key thoughts:

The most important base-level skill seems to be the ability to hold the concept of what I call "signal flow" (and others would call "state") in your head. The two jobs I've done in my life that I've done for money AND for fun are programmer and recording studio engineer. They are essentially identical. Hear me out:

When someone sings into a microphone, the signal travels through a cable, into a pre-amplifer, then an equalizer that cuts out the low end, then a compressor to limit the dynamic range, maybe you add some reverb and some delay. You need to be able to understand what is happening to the signal at every stage. For example, if you run the signal into a compressor BEFORE you cut out the low end frequencies with an equalizer, the results will be dramatically different. If you add delay (an echo) to the signal and THEN add reverb, it will sound different and you probably won't get the natural sound you are looking for.

When I was training audio engineers, if they didn't QUICKLY grasp this concept, they were most likely going to struggle.

Software is pretty much the same. You need to know what each function is doing, the state of each variable as you step through, etc. If someone without any programming experience has trouble following the value of X:

X = 10 Y = 15 X = 5 X = Y+X X = ?

Then they will struggle learning.

More recently, software has become a question of having a wide range of shallow knowledge, and the ability to google really well. But I think the fundamentals are the same.

I like your analogy, perhaps because I was a musician at one time lol.

I always used to analogy of cooking. You have ingredients, and you want to bake a cake. Slapping all the ingredients in the bowl at once, won't make a cake. You need to know what to add, when to add, how much to add, how long to bake it, what temperature, and the order of it all. (good recipes are algorithms after all).

Once the cake is made, do you have the tenacity to improve (troubleshoot) it? The cake is way too sweet!!! Can you figure out why? Was it too much sugar or too much icing? Was there sugar in the milk? Perhaps caramel would be better than sugar, etc..

It takes a certain style of of thinking. One that requires, like you said, knowledge of the "state" of things, but also it requires accounting for many possible outcomes of said states e.g. input sanitization and/or input validation.

It's not a forest vs. the trees style of thinking, but the forest AND the trees. The deeper you go, the larger and denser the forest becomes.

This is exactly why I really like functional programming / OCaml. It feels like piping modules to let data flow through, which is an abstraction I seem to be most comfortable with. Unlike OOP, which is nothing like this and offer a much more "realistic" abstraction (e.g.: the typical Vehicle > Car analogy), that in my head crumbles a lot quicker when faced with programming problems.

I usually say that it's good for everyone to give it a try and ask what they want to do. If they just want to learn for learning sake or because of a plan to switch careers, I'll mention python casually and then I'll wait. Most people will give up after trying it once or twice and that's fine. I never actually had anyone stick with it enough that they wanted structured help.

I do know a few people that got into it later in life, but those just did it, they didn't ask friends how to get started. So usually when someone asks, I unfortunately immediately predict they won't make it - since everything you need is available online, a person that asks already is showing lack of motivation or "digging" skills.

I had a coworker who was a Disney World character, voiceover actor, and then a flight attendant before going to a coding bootcamp. 12 weeks in a bootcamp and she was a solid junior frontend developer. I think that path is very achievable for a lot of people. I'm not sure if it is possible to take that route and go directly into distributed systems engineering, machine learning, or architecture, but depending on what "get involved in software" there are lots of paths from no experience to entry level.

People discover new interests all the time. Usually driven by crossover they have with other interests.

Computing is now such a ubiquitous part of life that it's interesting to a much broader set of people than it once was.

I won't assume this is true of you, but I'd say this assumption a lot of programmers have that they've always been intrinsically interested in computers is cart before horse. It's probably more that computers were relevant to other things they were interested in - themes like math, gaming and sci-fi - and that provided the hook. The intrinsic interest came later.

Being real about it, these were some of the only major themes that computers were relevant to until relatively recently, and that's a decent explanation of why we see a concentration of people with those interests in the industry today.

As the relevance and impact of computing broadens out, massively, we should expect and welcome a much wider array of people becoming interested in it where in the past they wouldn't have been. It's not that they are coming to it late, they are exactly on time for it to align with their interests, just as it was for you.

You should use the benefit of your experience to encourage and help them to get started!

I don't think your ability to learn decreases (that much) with age. However, being older also means more responsibility, which takes time. It also probably means whomever you're talking to already has a mean to earn a living, so to get into software engineering represents a rather large opportunity cost. It takes a huge effort to start over at the bottom, both in terms of salary and self-esteem. I talk to a lot of people who want to switch to software, few do.

Bootcamp is a really good shortcut. It's no surprise that most bootcamps arrived at the conclusion that front-end dev has a lower barrier to entry and focus on that. Kudos to them. It's a great way to get started.

Working a software-adjacent job can also lead you to software (I took this route), whether that is being a data scientist, data analyst, or any job that might benefit from a bit of python scripting. It greatly reduces opportunity in some cases (for example, a lawyer who leans to code to help his day job), in other cases, it simply delays it (if you really want to switch to SWE, you kinda still have to start at a junior position at some point)

Self-taught is absolutely possible. But it also means you have to do both the course planning as well as the learning, which adds another layer of challenge. It really takes a lot of dedication to go this route.

Software is unique in the sense that your skill becomes obsolete much quicker than other fields. It's a double edge sword - on one hand, you have to constantly learn new things, on the other, this dynamic creates a lot of jobs, because you don't have to wait for people to retire or switch jobs. A 3 year react dev is consider senior, same goes if you have 2 years of prod experience with k8s right now. You just don't see that in other fields.

> It seems impossible for me to recommend someone do this stuff without having that lifelong level of understanding and context and passion.

Your lifelong learning and passion are a key part of your identify, and most probably the reason why your friends respect you and trust you enough to approach you about software.

Unless your friends are trying to replicate you, it won't be necessary for them to develop the same lifelong understanding as you. If all they want to do is to learn about software, they could just learn a little bit about it, or as much as they can given their late start. That might still satisfy them.

If you want to be a good friend, it's important for you to distinguish between their ambitions and your passion. Try to see things from their point of view, and only share as much information as is necessary for them to be able to see the next step of the big picture.

For example, if they don't already know any programming languages, you could just tell them that there are different languages that suit different applications, and ask them what they are interested to work on. Don't talk in detail about the merits of particular languages because they won't be able to grasp these details yet.

If they say they just want to be able to program Excel, or to write an app to help their grandmother remember something, then you just need to tell them about the tools that exist for those applications.

Don't tell them too much. Just point them towards the right starting point, and tell them they are welcome to bring more questions to you as they arise. That will keep the conversation relevant to them, and avoid the difficulty of having you talk for too long about things they can't understand or appreciate yet.

> Am I wrong? Is software really not that hard, and able to be learned later in life?

As usually, it depends. If by getting involved in software you mean "passionately doing software for software's sake", they are likely late. If you instead mean "getting a superpower helping you think through and implement solutions to your not-computer-science-problems" then they are never late.

There has been some discussion whether everyone should learn some coding in the school. Frankly, I am quite irritated by some commenters arguing that it is not necessary because "not all are going to be software developers when they grow up". Well, not everyone needs to be mathematicians and we still teach some math to all kids. And not everyone are going to write novels, but we still teach kids to write. As I said, wring code is a superpower to thinking, and any curious mind should be encouraged to at least have a look.

(I am commenting as if the question is about general interest in coding, not career change towards software development.)

If you find yourself in a job where the engineering culture doesn't suit you, immediately start looking for a new job. You don't have to rush into the next job, be as picky as you need to be, but don't continue doing stuff that go against your beliefs, or stuff you don't want to do.

Changing culture is an insane amount of effort for lead positions, and an impossible one for anyone else.

Respect yourself or your mental health will start deteriorating. If this trend isn't caught early, it can take a very, very, long time to recover. It can also be be expensive, and I'm not talking about just monetary cost of therapies, but it can cost you in many other domains. And it creeps up on you, trust me; you don't notice until it's too late.

Depression/stress (burnout) literally damage your brain on a physiological level. It's no joke.

Wonderful advice. I am dealing with this right now, and I:

- I can't believe how much useful knowledge I have lost (or at least would have rather still retained, perhaps useful is the wrong word)

- how difficult the smallest things are now

- how long it took me to realize the ship wasn't sinking -- it sank years ago, and I'm already lost at sea.

Time to brush up, and find enough driftwood to make a raft, I suppose.

I don't even care about titles, more pay, etc.. I just want to make things that I can be proud of again.

> Depression/stress (burnout) literally damage your brain on a physiological level. It's no joke.

No kidding, and I am finding it harder to get back on the horse and self-study (I feel like I lost 90% of my fundamental knowledge since college. Use it or lose it, I suppose). I want out of web development, and I would love something lower-level, but I am not sure where to even look. I am sick of .Net Core and Sql. I want C and ARM assembly (good thing I forgot it all). I rather program a dishwasher than another web app at this point.

It's easier to never fall off the horse than it is to get back on. Lessons learned.

This advice is good in general, but I don't think one should do job hopping right away fresh out of college or very early in the career.

Yes, good point. It's probably wise to stick around for at least a year or two in a company (subject to situation and your judgment, of course).

Just understand that it’s not a coding career it’s a problem solving career. Often times the best way to solve a problem are good social skills, empathy, dressing well, and generally making your soft skills strong. It also helps to be persistent and willing to try things repeatedly and failing. “Good” coding skills are often not necessary. Know the basics, be willing to learn, be outgoing (introverted doesn’t mean you can’t be social and outgoing) lean on others and you’ll go further than you expect

Edit: unfortunately you’ll need to know Leetcode to break into a lot of jobs. Honesty just memorize solutions for two weeks. It sucks but it is what it is and it’s easier to go with the flow than get angry at it

I’m currently doing what your friends have expressed wanting to do by enrolling in launchschool.com, which is $200/month and will give them a great taste of what learning how to code entails… I’ve been thrilled with my experience so far.

+1 on Launch School. Did not attend, but have hired and worked with couple of graduates. I highly recommend it to anyone wanting to enter the field.

I told someone to go to a coding bootcamp (they were from an Arts degree). They went to one in Brooklyn, worked for a couple of startups as a junior, got terrible pay for a couple years. Now she makes like $100k+ only a couple of years after taking the bootcamp.

I'd say do it.

---

On the other hand, if someone likes the idea of writing code itself, I'd say don't go to a bootcamp — learn python from FreeCodeCamp — there's a whole world out there that you can do if you learn how to manipulate computers and data

> ” Am I wrong? Is software really not that hard, and able to be learned later in life?”

What? Of course you are wrong. It sounds completely alien to me why someone would even have such doubt. It sounds arrogant too.

Anyway, to your question, tell people to try for themselves for some time and let them discover if they have joy coding something. Joy is important.

It is completely ok to get into software development for the money, but if you don’t enjoy the daily work of programming something the chances of you get a rewarding career out of it are slim - personally and financially.

Software development is different from some fields in that you have to continuously study software development. That does not really happens with most office jobs (marketing, HR, finance, sales) and happens in a much slower pace in field jobs (plumbing, carpentry, etc). That’s why joy is important.

It is very possible that someone could discover the joy of programming later in life.

My personal recommendation is to go with www.freecodecamp.org. Try it for a couple of months and try to identify if you like going through the tasks. And if you get happy after solving a particular trick one.

freeCodeCamp is free, well done, with very small tasks that allow you to adapt to any schedule you might have for studying.

You’re gatekeeping. Learning is possible for anyone with adequate access to information and support from experts. Be the expert that teaches. Do not be the expert that obfuscates information in order to protect their ego.

If you feel something is too complex to teach then do not teach that thing. Learn that thing better from experts who have simplified that complexity into an elegant framework. Then teach that thing.

In the "old days" there was a dividing line we noticed in class. If the student could understand pointers they would succeed, if not they wouldn't. It was quite accurate for the time.

Today things are higher level so I think there is room for a wider range of folks. One group are folks that are great at spreadsheets and the like. Gamers or someone who is interested in tinkering with javascript. Perhaps they have a technical career that requires attention to detail.... a tax lawyer, medical billing, accountant? Music? Ok. Otherwise it will be tough.

My first thought is to sit them in front of the PBS Computer Science Crash course series. (Can be found on Youtube but need NewPipe or PBS app to watch commercial free. Watch at .8x speed or slower, because I feel they speed it up to appeal to hyper teens.)

If they can get through to the last episode before giving up, I think they deserve a shot and encouragement.

> If the student could understand pointers they would succeed, if not they wouldn't.

What were common hang-ups that people had with pointers?

I guess, it's safe to assume I am of a younger generation than you, but I may have had a bit of an unfair advantage (compared to my peers) when I dabbled with C because I studied assembly (x86 and a bit of ARM) prior to C, so pointers weren't exactly foreign concepts.

I do not think about this on a daily basis, so it's easy for me to forget how good things are these days. I can't tell you the last time I even thought about/used pointers, since I mainly use the fancy "magic under the hood" languages these days. For pure geeky fun, assembly and C were my favorites... Something about the memory management and pain brings back fond memories, even if I never made anything overtly special with them.

As developers know, pointers require you to work with a variable that points to another variable. It is one more level of indirection, and one needs to keep additional information in short-term memory to understand the code. For whatever reason, a significant portion of students can't deal with it and give up. At the time, there were no "CSS expert" type of jobs to focus on instead. Perhaps Excel jockey or IT management as mentioned, but a different major entirely.

Perhaps one reason is that the traditional C syntax for it is rather cryptic. Personally, first learned it in (Turbo) Pascal, which I found easy to learn (with its ^ syntax), and with that made learning it in C easier later.

I'd probably ask the same thing I do of everyone who asks for career advice: "What kind of problems do you want to work on?" Similarly, I'd ask: "Imagine you are getting ready to retire... What do you hope to have achieved? What does your CV look like at that point?" IE: begin with the endgame in mind.

This might get them to reflect on whether software is where they want to spend their energy and time. If so, then great, figure out how to get them pointed in the right direction. But, if they realize they are mostly interested in software because they've heard stories about sweet money and fame, maybe it isn't the best choice for them.

IMHO you can't really be a software developer without knowing and understanding computer science. Some try but never move beyond web/front-end stuff, which is fine, we need people like that. It is however only a small subset of actual development.

Like any field based on science, you can't really drop yourself into it and expect to do well. You need an education in said science.

Obviously there is the self-taught crowd, who are a special breed who love life-long learning. This takes time.

My recommendation would be to show anyone with an interest in software development the Python REPL. Using REPLs gives a good taste of the concepts of programming without all the foreign concepts of IDEs, etc.

I remember about a decade ago, there was this site that let you generate these silly animated videos out of just text scripts featuring two people sarcastically talking about various careers. "So you want to be a lawyer" and "So you want to be a social worker", etc. Of course, there is a "So you want to be a software engineer"[1] and although it's a little over the top, I still point people to it.

1: https://www.youtube.com/watch?v=WkXzlkOWLE0

I wrote a blog post answering a related but different question about bootcamps: https://offbyone.us/posts/things-to-consider-before-joining-...

I feel like there are many paths to computation and I’ve met many people who have become functional technologists from various backgrounds. I think the most important thing to figure out early is do you like programming. Do you like this kind of thinking?

I also like to ask people: "What would you like to do once you know how to program?" That tends to filter out the people who want to do it for the money, and leaves the folks who have some curiosity.

I like trying to help people figure out a problem that they can solve, in their own life, by writing a little software. Reformatting spreadsheets is a perennially good choice. Every office worker can use that.

Beyond this - I like referring people to Peter Norvig's essay, "Learn Programming in Ten Years".

I get this question so much that I wrote a book on the topic. Everything I wish I knew before I wrote "Hello World".

I usually offer a free copy of the book and they get really excited.

After a month or so, I sometimes hear back about what they learned from the book & how they are applying it to their journey of becoming a software developer. Those who stick with it usually land jobs within 12-18 months.

Otherwise I don't hear back from them at all. Their loss.

Software is hard, but unlike many other professions, you can do useful work at almost any level of the learning curve. Even for those of us with many years of experience, there's always something new. You can use an argument within these lines. Remember them it's a journey. One can start with bare resources. It's not capital intensive and there's no need to put themselves in debt.

If they want a job in software development, point them to Reddit. There are a number of posts and subreddits focused on transitioning into software.

People will go into detail about their learning path, projects completed, and hours spent learning.

It is highly US centered, but it definitely seems possible for someone to start late in life and learn enough to become employed as a developer.

I usually say this: if you'll start today, spend 1-2h every evening and weekend over the next couple of years+ read hundreds upon hundreds of websites, documentation entries,etc, then you should start grasping it. For 99% of people mentioning 'years' is enough to kill any ideas of doing it, because most just want a quick solution.

So you just give intentionally demotivating advice? It doesn't take years to learn software development and you don't need to scan hundreds of pages of documentation. If we're talking about it as a profession, sure maybe, but that wasn't implied in the OP. "Building" software can be as simple as writing Hello World or a calculator.

My answer is usually to those who are thinking of getting into the field,not just write some 'hello world' apps. I don't demotivate, I do give a fairly realistic picture: it does require a lot commitment and lots of hair pulling moments to get somewhere. The problem is that those who really want to do it,they never ask, they just dive into it. The ones who ask, are usually who will never do it or have an unrealistically simplistic picture of what it entails. I used to offer this route to non technical colleagues,who,if wanted, could have doubled or tripled their salaries in just a few years. I was offering all the support they'd need,should they decide to do it, including the company changing their roles if they see the motivation. Nobody ever took it. Not a single person.

I've met people who just graduated literature that got hired out of diversity as a software engineer in a well known company and then learn the basics on the job.

So tell them anything is possible apparently.

You need these attributes. i) Tenacity ii) Eagerness to learn. Always. Research-orientedness is a must. iii) Willingness to solve problems, not just your own.

Pick a good intro course for them.

Give them a heads up it is not for everyone. If they can grok the course. Give them another.

If they can’t get past the first course, have a heart to heart.

Why not let them get a taste of it with Swift Playgrounds if they have an iPad? That way they can find out if they like it or not.

Whatever you do, don't get into gaming.

can you please elaborate why?

i plan to start learning to code and making a game would be one of the final milestones on the loose roadmap i've set for myself -- i get it's complex but would love to know why you advise against it.

Games are great for learning programming: one of the first programming projects I can actually remember doing was a Pong game written in BASIC when I was 19 or so.

However, game companies have a reputation of being terrible to work for. https://en.wikipedia.org/wiki/Criticism_of_Electronic_Arts#T...

ah ok i see, thanks for clarifying. thankfully i don't see myself working in that industry.

>can you please elaborate why? i plan to start learning to code and making a game would be one of the final milestones on the loose roadmap i've set for myself -- i get it's complex but would love to know why you advise against it.

Making your own games is really fun and rewarding. Highly recommended. But the games industry works more like Hollywood than Silicon Valley. Games are either a hit or a flop, and they have very tight release schedules with hard deadlines like a movie. The resulting work environment is notoriously terrible.

I'm not the person you're replying to, but I have a bit of insight here. I've been happily employed in the games industry for the past 10 years and don't have any plans to leave it, but while I have absolutely recommended programming/software dev as a career field to people before, I would hesitate to _suggest_ the games industry to someone who wasn't already excited about it.

To your comment, making games is great and fun and I think it's great you want to do it. Working in the games industry is different from making your own games though.

For one - you pretty much will never have creative input on the game you're making as a programmer (unless you're on a really small team).

Probably the biggest reason to avoid the games industry is salary. Game developers make less than their peers in other areas of software development. Lots of people blame this on there being a huge supply of fresh grads to hire cheaply, but that explanation feels like a myopic/simplified view from people on the outside looking in to me. My opinions aside, the fact is that if I left my job today and got a job programming something that wasn't games, I'd almost certainly make more money. I'm paid well enough to live a very comfortable life, but if your goal is just to maximize how much money you make, game dev is a bad choice.

Next thing to point to is crunch. Game development is notorious for "crunch" (aka - long periods of 70-80 hour weeks). Some studios do this more than others. It always sucks. It's also a fact of life in games. Even teams that "don't crunch" will usually wind up doing something like it at some point. I honestly have no idea if other programming fields do this too, it's just a common criticism that I've seen levelled at games industry jobs.

Being a game developer also means that you're not working with the kinds of tech stacks that the larger software industry as a whole is using, which feels like it would make switching fields more difficult (not that I've tried). For example: I haven't had to build a real database since college, have written maybe two unit tests in my life and don't think I've ever worked anywhere that's used the C++ standard library, despite working in C++ for most of my career.

It's also super unstable. It feels like most game studios will close (or transition to not making games) within ~10 years of starting up. Layoffs and studio closures are also a really common occurrence. Every time a meeting gets randomly added to my calendar at the last minute, my first thought is that a layoff is going to be announced (even though this has literally never happened at my current job). This is less of a concern at large studios (although definitely still a thing), it's a huge deal if your dream is to work at indie studios though.

There are lots of great things about working in games, but the above wall of text are some of the reasons why I'd hesitate to encourage folks who aren't already interested in the field to choose game development as a career.

thank you for the insightful and detailed reply.

making this game i've envisioned is more of a carrot on a stick, a clear goal that forces me to learn loads of different stuff on the way. whether or not the game itself ultimately materializes is not as important as picking up new skills, and i definitely don't see myself working in the games industry (nor the IT industry).

hell yeah, making a game just for fun or to learn new stuff is the best. Good luck!

have a burning goal in mind that programming solves as a means to that end.

I might add to that. While you're learning, it absolutely helps to have lots of little project ideas. And then later it's nice to have a hammer in a world where everything is nail-shaped.

This is more electrical engineering than computer science course. And it’s timing is absolutely not realistic for a starter. 12 weeks is a bad joke for this. Half week for uart design. Lol. Beginner has to know what uart is in very first place. For 52 weeks it might be ok if you are senior level.

Well, the best way is always the hardest. If you want to a quick way, you can go to bootcamps, 3 months, and you'll be okay to go. But for a long term investment, this is the best course ever to learn the CS.

Encourage! Be a supportive friend!

Re-consider wood-working instead.