Ask HN: Is it normal in this industry to receive almost no training?

[J-dawg]

Background: I'm a struggling junior/intermediate frontend dev who would have quit this industry long ago if I had any other way of making money.

Ever since I joined this industry I have been surprised and disappointed how little structured training I have received. I am wondering how normal this is?

With the exception of one team that did a lot of pairing and was great, my experience of joining a new team has generally been "look around the codebase and see if you have any questions", with perhaps a couple of days of pairing, or being assigned a buddy who loses interest after a week or two. Mentioning that I'm struggling generally results in someone recommending Udemy courses, or asking "how much time do you need to get up to speed?"

I guess I expected something like a technical lead who would initially spend a lot of time talking me through everything, then maybe start giving me small tasks and working through them with me. I've literally never seen this. Even the "pairing" team basically only did it because we all got along well.

My initial years of experience were in consultancy companies, so I put it down to that: there's a pressure to act like every member of your team is an expert when they are being charged to the client on a day rate. But I've since joined a big product focussed company and the experience has been exactly the same (and massively exacerbated by working remotely for a year).

As I result I've become the classic "one year of experience five times over", rather than "five years experience" guy.

I don't want this to read as a complaint - I'm fully aware that many people thrive in the environment I described. I've seen them thriving! I'm mostly just curious. It's too late for me anyway, I'm clinging on to my current job until I get fired or figure out what my next career will be.

I guess I just want confirmation - is this industry only for people who very self motivated and don't expect any hand-holding?

[giantg2]

It's completely normal. Companies don't want to train. You can even see this in the discrepancy between how many senior level roles are posted vs the low number of junior/intermediate roles posted. They want experts, but there's no real source for creating them since nobody provides that growth/feeder environment.

"one year of experience five times over"

I sort of have this too. I did become the guy with 5 years experience at one point. They decided not to promote me (I'm intermediate and was acting tech lead) and violated some policies to my detriment. Then they outsourced me and my team. Two years later, they shipped that entire sub-org over to another company they are "partnering" with. So I guess I'm trying to say that the industry can screw you whether you have 5 years experience or 5 single years of experience.

[killtimeatwork]

> I guess I just want confirmation - is this industry only for people who very self motivated and don't expect any hand-holding?

I'm afraid that's mostly the case. That's why it pays so much BTW - you're expected to be thrown into a middle of complex shitstorm and start delivering value soon afterwards. In return, you get a salary in 90-95th percentile. My best recommendation is to not change projects too often - after at most two years on a project (unless it's some absolute behemoth like MS Word or Unreal Engine), you become one of the project elders, who touched most of the areas of the code already and for whom working is a breeze.

[tkiolp4 → killtimeatwork]

This. I think this is the only reason why IT pays so much: it’s difficult, there is no documentation and you need to educate yourself.

[muttled → tkiolp4]

It's a weird situation where you can make 60k+ pretty early on in your career but still get yelled at more than you really thought you would as an adult.

[tdy_err → muttled]

Muttled, no paycheck is worth putting up with someone yelling at you

[gbtw]

Most of the commercial consulting companies i worked for found investing in their staff a waste of resources because they can walk away when they know something, yet wanted you to stumble around and be ineffective when using new technologies, mostly because that time was billable to a customer. Learning was after hours.

I work for a government organization now and they have a yearly budget for courses and access to some of the large course platforms and the requirement to spend 4 hours a week on it during work hours/ on company time.

[mattm]

> results in someone recommending Udemy courses

I don't want to sound snarky but have you taken those Udemy courses?

That's pretty structured training. Sure, it's not specific to your codebase but the foundations would be applicable. Also, if you ask someone for advice and they give you a suggestion and you don't follow through on it, don't be surprised if they're less than willing to help you out the next time. Even though the advice is not exactly what you were looking for, you might find it more applicable than you realize. Take the course then circle back with them and say something like "hey, I took that course you recommended and I had a question about X from it. Do you have a minute to talk about that?" Most likely they'll take the time because you've now built some trust with them that you're open to their advice and feedback.

Yes, you do need to be somewhat self-motivated. If you get more value from listening than reading, then yes things like udemy or coursera are something you should be taking and watching a little bit everyday. Most reasonable companies will pay for it if you go to your manager and make a case for it.

> I expected...a technical lead who would initially spend a lot of time talking me through everything, then maybe start giving me small tasks and working through them with me.

A technical lead may have years at the company. Expecting them to walk you through "everything" is unrealistic. If you're not getting small tasks, then yes, being proactive and asking for small tasks is important. Figure out what specifically you're stuck on and ask for specific guidance. Asking for someone to "spend a lot of time talking you through everything" is not going to go over well. You won't retain much of it and it will generally be a waste of time for both parties.

Think of learning like concentric circles expanding outwards. Start on a very small thing and complete that and then slowly expand outwards. It sounds like you want to start the other way. It doesn't work like that.

[chrisbuc]

> "Looking around the codebase and see if you have any questions" ... getting up to speed...

I like to do this (explore the codebase) with any new code. My approach is to pick a piece I'm interested in (eg, auth, orm, some api integration), and either: a) see if I can just develop that bit from scratch using the codebase as example - that really helps with my understanding of the required components that get that bit working, or b) delete non-relelvant bits of the codebase until just that bit's left and it's not broken. Then you can tweak, extend, explore, experiment, and slowly add other bits back in.

Point b) works well with tearing apart smaller github projects to see how the bit I'm interested in work, less so with a large codebase.

But tbh, yes, it's pretty much sink or swim. I expect to be put on projects with little backgroud knowledge and expected to get myself up to speed and be productive. Anything else is a bonus.

Where structured training has really helped is in the softer skills, like project management, problem analysis etc. This makes it easier to communicate common concepts, thoughts etc to people who aren't just devs (eg, being able to put a timeline on a problem, identify a change point, and perform root cause analysis that leads you to fixing a fundamental bug). These are skills that you _could_ absorb through good company practice, but better to spend a day learning and be on the same page.

[ilaksh]

Udemy and Coursera and a lot of those I consider to be very good training.

I have a theory. Have you somehow been led to believe that you are supposed to remember everything? Because a big part of many software engineering jobs is literally Googling and then "training" yourself quickly on info relevant to your task. And also referencing things.

So the next time you feel like you wish someone walked you through something, go on Google and type "walkthrough X". That is what your colleagues are doing, unless it's just something they are already really familiar with. But it's normal to not be familiar with everything because there are new technologies being invented as fast as people can type them in.

To me reading comprehension is a big part of problem solving for most projects because you are never starting from scratch, and you are never going to be an expert on every new subproblem. Unless you deliberately write the same type of computer program in the same framework every single time.

I'm not saying there aren't core skills and knowledge that can apply over the years. But you are definitely going to need to be able to train yourself and use google when you can't remember something. Or use Udemy or whatever for more fundamental skills.

[airbreather]

They are paying you to make problems go away, they expect you to do this by whatever means is available to you.

Sometimes they might decide it is in their best interests to train you in some area so you can be pushed down a certain path, often not.

The don't pay in the top 10% (and often in the past to people with no formal quals) because anyone and everyone can do this, it can be hard.

You will likely burn out if you don't do it for some underlying fundamental aspect of joy not related to the direct or promised possible remuneration, even if it is just getting to make the "right patterns" as part of your work.

If it distresses you, start to think of other things to do.

[dennis_jeeves]

>I guess I just want confirmation - is this industry only for people who very self motivated and don't expect any hand-holding?

The hand-holding part is correct. The 'self-motivated' part, well, I'd rephrase that as earnest corporate slave. If one is not an earnest corporate slave the job can be potentially soul sucking.

About the training part, while the language/framework hand holding is not expected the system specific architecture and specifics hand holding is indeed a must. Most teams skim or do not pay sufficient attention to the latter, resulting in a new hire not coming upto speed as quickly as he would ideally have.

[dusted]

I've never received any training, and I'm very happy about that, as I prefer to learn on my own terms, as the need arise, not as a pre-planned course after which expectations are that "now you know how to do that"

[J-dawg → dusted]

I didn't really mean training as in pre-planned courses. More sitting down with someone more experienced and being coached through a feature or a programming concept. I guess I was wrong to expect more of this.

[itronitron → J-dawg]

Not guiding new people on critical aspects of existing systems or codebases is an indication of weak management. I think it is fair to assume that a developer knows the basic concepts pertinent to a given role, however the behavior of working systems is usually determined by a suite of proprietary configuration that is going to be confusing for anyone new. Unfortunately the people most familiar with that will have the hardest time communicating it to someone that is new.

[tkiolp4 → J-dawg]

How do you think the college more experienced than you has learned all he knows? Could be through another experienced college, yes, but chances are he learned by himself. We, IT people, are somehow elitist when it comes to knowledge: we think meritocracy is the way. I don’t like it but that’s how it is.

[kat]

You may want to consider a new employer. Although the average company does not care, the good companies and good managers should care about supporting you! The "let them figure it out on their own" approach is even more common for folks who dont fit in the company culture. I've seen some juniors have a hard time and others not, because a manager will "click" more with one than another based on their own bias (oh he still lives at his parents house, he's weird vs oh he goes fishing like me, i dont mind helping him). Personally I feel terrible that I work in an industry that does nothing to support people. I've struggled through jobs with no support (and worked wayyy to many hours to make up for that). If you have free time, I would suggest job hunting as a "see what you can find" adventure. You might get lucky and find much better coworkers.

If you are interviewing for a new position, ask something about "how do you onboard new employees" , "do you have a mentoring program?" , "what does a developer do when they are stuck on a problem". If someone tells me I'm going to fix a bug on the first day of work, I always ask who is going to coach me through that! I watch how the interviewers interact with each other. Do they laugh with each other or is everyone in the interview silent and just listening to the boss? I also look for diversity on the team (some married, some not, some old, some young, etc) because where there is higher diversity there is more chance you'll click with someone who will be happy to support you. Explicitly state your job hunt is to find a more supportive culture that will coach you through your growth. Good luck either way!

[cosmodisk]

No other industry is like this one: most graduate and carry on with that knowledge for decades, occasionally doing a professional development course, where in this sector reading 200 pages of documentation in 3 days is somehow absolutely fine. When I look back at the jobs I did before,they all look super easy in comparison.

Going back to what you've written: what are your struggles exactly? Is it some of the concepts or the structure of the project?

[brundolf]

It's one thing not to get training on standard technologies that are publicly documented; it's another thing not to get training on internal systems that you can only hope to decipher through reverse-engineering. I've seen both, but the former is much more common. I don't think you can get away from that version.

If the latter is your main problem - i.e. you're willing to self-teach where material (like Udemy courses) is actually available - then one option is to look for a gig where you're the one creating the systems from scratch. That removes a big part of the problem, because you're the expert from day one. Getting into a startup at the ground level is one way to do this; working for a company that's always creating demos for other parties, like a design agency, would be another. (I also have a pet theory that enabling this kind of thing is a main motivator behind the microservices push)

[caffeine]

Remote working has definitely exacerbated the problem. Your latest role probably sees you as experienced and therefore requiring less hand holding.

One good way to get up to speed that I've seen is to say "there is no good onboarding for newbies, I will make one." Then go through and document everything needed to get productive. It gives you ego armour to ask basic questions because you are documenting the process, and it will force you to be thorough in getting yourself up to speed.

It will also make you the defacto mentor for new people (whom you should task with updating the onboarding guide), which is a very powerful thing - if you mentor new people, you will be seen as a leader and eventually you will be a leader.

[Jugurtha]

Recycling some replies. More context on https://news.ycombinator.com/item?id=26182988:

- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)

- https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates)

- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)

- https://news.ycombinator.com/item?id=22827841 (product development)

- https://news.ycombinator.com/item?id=20356222 (giving a damn)

- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)

- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)

- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).

- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)

- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)

- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)

- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)

- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).

- https://news.ycombinator.com/item?id=24177646 (communication, alignment)

- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)

- https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings)

- https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum)

- https://news.ycombinator.com/item?id=25922120 (researching topics)

- https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information)

- https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets)

- https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)

[ampdepolymerase]

What is your educational background? People who thrive in the software/computing usually have a strong STEM background/significant experience with solving physical problems, though there are exceptions. People skills may be valued by HN commenters but companies do leetcoding tests for a reason. In consulting you often have to go the extra mile to persuade the client or to make them happy. For computing it is the same but your focus is on being able to learn new technologies and abstractions rapidly. Most academic CS training follows much of the same route too, the ramp up from "CS 101" to higher level courses is often very steep.

Fundamentally software engineering deals with abstraction and complexity. Perhaps consider studying some backend? Knowledge across the stack will help you improve a lot too.

Try to gain a high level understanding of how to apply various technologies and methods. You can gain tremendous career growth by leveraging your already excellent people skills but you absolutely need to be able to follow a conversation between two engineers on a high level.

[rboyd]

There should be a bootcamp where you show up and day 1 is a painful scrum meeting where without any context you point some decades old ETL job you’ll be painfully refactoring all week.

Week 2 should basically be the same thing only you get paged to firefight a system outage while you work on it.

[HeyLaughingBoy]

It seems to be mostly confined to small companies. The larger orgs that I've worked for had no problem paying for training classes or tuition reimbursement if you wanted an advanced degree.

[Borrible]

<sarcasm>

   For God'sake, read the fucking manual before asking 
   redundant questions on HN!

</sarcasm>

[cmollis]

completely 'normal'.. I've literally never been trained on anything that I've actually worked on. The natural reaction to this is basically the standard 'google all the things' when you're working with something new.