Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to start afresh in a new domain after years of expertise in another?
389 points by vcool07 on Sept 6, 2017 | hide | past | favorite | 88 comments
Hi Guys, I have over 12 years of expertise in a particular domain. Now I recently switched to another company in a new domain (based on some overlapping technical skills and good recommendations from my past colleagues) as the jobs were far to come by in my old area of expertise. But, I'm finding it really hard to adjust in the new one.

The biggest challenges I'm facing are :

1. Looking at my years of experience my colleagues expect an expert level of performance. But being new to the domain, I've not been able to meet their expectations.

2. I've tried looking for non-tech roles PM, TL etc., hoping to leverage my management/leadership skills, but my senior management aren't buying it.

3. I feel isolated in meetings where everyone around me are talking the technology and I just take notes or stay silent mostly.

4. When I see guys half my experience are miles ahead of me in terms of the tech skills in the new area, I wonder if I even have a chance catching up ?

Any suggestions / advice is welcome and highly appreciated. Thanks in advance !




I've switched domains all the time (CAD/CAM -> Medical Imaging -> Genomics -> Web Development -> Internet Security -> VR -> Fintech), things I've found helpful:

1. Ask a lot of questions at the start. People know you've switched domains and will tolerate dumb questions for a while.

2. Don't ask the same dumb question twice.

3. Read a lot to get into the new head space. Set up google alerts for your company and its competitors. Join forums dedicated to your new tech and domain.

4. Offer learnings from your old domain, humbly. "At my last gig, we approached this <method>. May not apply." This shows everybody you have things to offer but you are just getting your sea legs.

5. LEAVE THE OLD JOB. All of the above things you did for your old gig. Stop doing them, you don't have time anymore.


I couldn’t agree more. As a strategy consultant I do have to face new clients on a regular basis. Sometimes the industry / topic overlaps with the previous engagement - often not.

1.) Really, really, really ask those dumb questions in the first week. Everyone will tolerate it and even expect it

2.) Learn the basics of your new domain / industry top-down asap. Meaning: understand for what your company gets paid for, understand the basic process how it gets delivered, understand the strengths / weaknesses of your company. Know who the key customers are and what they really want. It’s often the new guys who are empowered to challenge those high-level topics while everyone else takes it for granted (and often have the wrong idea in mind)

3.) Always ask a question / say something during the first five minutes of a meeting. It just gets harder and harder afterwards. But as soon as you asked you’re in the game

4.) Bring in experience from the past but try to take the extra mile of translating it as much as possible to the new situation (“at my last gig we did... I understand that here we have... however I see further potential in...)


Two to add:

5.) Ask a colleague to give you a dedicated intro session. Not just a random “I show you some stuff on my PC” but a real one. Typically a nice way for the colleague to reflect on their learning as well and/or prepare a public talk :-)

6.) Be aware that almost no one really knows. They are all bluffing, they are all biased. There are exceptions but they are super rare. Even someone 2-4 years in a specific job will get his stuff done but still struggle with some concepts. On Management Level it gets worse as those guys tend to not have the time to digg into it


Can't stress (6) enough. Most people do stuff because that's what they heard first or it's a solution they found for a problem that existed years ago. Having a new perspective and questioning existing norms is healthy. You can add value there more than most of the existing "tribe".


When you do 5.) show them appreciation - buy them a nice meal as they explain things to you - it's a nice thing to do, a small price to pay, assuming it's appropriate


At our company when I was on boarded we had a process called boot camps. Which was basically a week set aside with meetings for each respective team/department to get a high level over view of what they do and how they fit together with the company as a whole. This gave me some good insight on how I fit in as well as open up new dumb questions to follow up with.


Definitely 5 - not only do you learn a lot, but you also learn about different people's learning/teaching styles too. You also pick up on the political landscape, as well as priorities.

Had the best intro in my previous job where the first 2 weeks were dedicated to learning and meeting people. Overwhelming, but good chance to really crack on with it.


These are great! An important caveat for 5) is to make sure you have done the ground work before asking! There is nothing worse than spending valuable 1-1 time with somebody who hasn't even done the React tutorial yet ...


1. Intelligent people ask questions. There is no reason to stop after the first week. Connect the dots in the open and people will understand that you're intelligent. "Why do you <technical detail> here?". "Because of X". "Ah, so it's basically the same as using <technical detail Y>." Just show that you are able to take in the new information.


4) Is excellent; so much of your first few weeks are about perception. You want to be curious, engaged and trying hard AND you want to show it.


May I ask ...

- Were there any times you got a job in a new domain without any experiences (e.g. didn't worked on as a hobby project, didn't do extensive learning the new domain by yourself)?

- Any ideas why those employers chose you for the job? (e.g. purely because of your past experience from the old domain? Any specific qualities they saw in you?)

- How much effort (time?) you would normally spend to learn a new domain before applying for a job? Or if time is difficult, what criteria you use to determine that "Yeah, I'm ready to find a job in this domain"?


I got a job once as a producer for a video game publisher and had pretty much no experience. That first couple of months was basically an intense crash course on video editing (Adobe Premiere and After Effects, had never used them before), localization, qa outsourcing, certification, working with external dev teams, figuring out how dev kit machines worked, evaluating pitches and game demos to see if we should pursue publishing them, etc.

Before that I hadn't done much more than develop and self-publish several Flash games, sometimes collaborating with an artist.

They chose me probably because they were tiny, could tell I was passionate about games, and they expected I would do more game design than I ended up doing (my title was Lead Game Designer... I did some of that, but I was mostly a producer).

And since I thought it was mainly a design role, I didn't hardly anything to prepare. Once I got there, it was like someone volunteered me for the Ice Bucket challenge and didn't tell me before dumping the water on me. Had a lot of fun, though.

Only reason why I'm not doing it now was because I felt like my coding skills were atrophying the whole time I worked there and that thought made me feel pretty uncomfortable. I'd probably be more successful now though if I stuck with it, though.


I have a bit of an unfair advantage in that when people look at my resume now they have no problem believing me when I say I'll ramp up in the new domain. I've professionally used C++, C, C#, Fortran, Java, Javascript, Python, Tcl and multiple stacks so it's not too hard to ramp up on a new technology stack.

I normally ramp up on the company and space for at least 6-8 hours before the interviews start. I take the approach of a customer and try to figure out whether I would buy their product or not. I tend to ask questions about competitive threats and possible pivots that show you grok the market. Sometimes I discover competitors they have never heard of, this sometimes kills the job :-P

If you have the technical chops, you need to show you'll use them productively as soon as you hit the ground.

I'm also both a manager and a developer and can easily plug into multiple roles. I'm happy to roll up my sleeves and program while building the team.


I would also like to know more about getting in. I'm confident I could get up and running in a matter of a few weeks working fulltime on almost anything. I just have a difficult time getting in.

Right now I'd like to go from embedded to data science, machine learning. I think I have some useful skills. But I obviously can't show much in terms of SQL knowledge. I've used python pandas for a few internal tools. I have a solid background in statistics from uni, but I feel like after some years in industry, people don't care about your uni background anymore.


If you work in embedded, start to shift your focus into IoT. Internet-connected systems are the ones producing and storing the data necessary for data science/ML to happen. Experience with the data ingestion layer IoT cloud platforms (AWS IoT, GE Predix, Azure IoT Hub) could help you transition to higher level data analysis roles, especially if you can demonstrate your domain expertise with embedded systems. If you are working with Matlab along w/ Simulink, you should check out ThingSpeak: https://www.mathworks.com/products/thingspeak.html

If you are working deep embedded/legacy products or purely on the hardware side, you may need to grab an ML course/certificate to signal your interest, or just network really hard. Having embedded engineering skills can't hurt though.


Everyone wants to do machine learning; you need to fight for it to get there.


why do u want to leave embedded?


At least in my industry all the application layer gets done in Simulink. I prefer working with code. I find working with Simulink frustrating, you can't diff properly, simple things are hidden in hard to find configurations. It just doesn't work well with how I like to work.

Three other option is going back to firmware, which I did in my previous job, but I don't want to write more firmware drivers. It's just not exciting.

Additionally I'd also like to do more creative work, I find data science sounds very exciting and I could probably bring a lot of software skills to the team

But convincing the industry to go another path is probably harder than switching fields.


Please don't fall for the "sexiest job of the 21st century" adline.The wife works as a sw dev on a speech rec team(one of the popular ones) and she works with P.hD "Data Scientists" which are looking at getting in to dev. If you apply the pareto rule, "Data science" is 80% Cleaning and 20% ML. Hardcore ML research is totally different which requires atleast a MS with ML focus and pedigree plays a huge part. Here is a thought. Why don't you try rewriting stuff you did with Simulink in Python. My man, Downey got you covered https://github.com/AllenDowney/ModSimPy. I would recommend that you start with Think Python before tackling this book.


I went from Astrophysics > Computer Security > Genomics > Alzheimer's research > AI > Medical imaging

The secret? Stop worrying about not being an expert in the area. Be friendly with coworkers and immerse yourself in the new field. You will pick it up, even if the verbage doesn't make sense at first.

While doing this, exercise regularly, since this promotes neural plasticity, which is needed to learn new things.


> I went from Astrophysics > Computer Security > Genomics > Alzheimer's research > AI > Medical imaging

With half of these jumps I'd be worried about Impostor syndrome.

With all of these? About Dunning-Krueger.


I don't believe there is such a thing as a dumb question. If you don't understand something, have the confidence to ask - at any point, not just week 1. That way, you will learn. And more importantly, people, especially those who know you just started in a new domain, will see that you are developing yourself. Who cares, if you upset some delicate flowers that don't like getting asked questions they think are below them.


Thanks for sharing, this is really cool. Can you please share with us what did you have to learn in order to get into Fintech? If you were to assemble a short bullet point list of essential topics to study for the job, how would such list look like?


Once I was asked to start working on an app in a new domain, I had never worked in that domain and without good enough knowledge, working on that app would be crazy. The first 2 days in it and I realized, there has to be some systematic way of going about it.

I brought it up in the next weekly meeting, asked for a resource (book, session by colleague, video anything) from the team already working on it. They recommended a book and I explained that I need to work through the book while correlating the app with the book and working on bugs/features, all the same time while explicitly stating that I need some time/guidance to be up and running.

That was taken very positively and in a few weeks, I was productive as per/more than the expectations, while following the steps outlined.

Don't worry, be pro-active, ask, make a plan with the team and follow it. The more you do nothing about it, the worse it might get. Best.


The expert performance that you should be bringing is not your mastery of this particular technology. Your strengths should be:

- experience with infrastructure, so you don't need to have underlying things explained to you

- experience with team projects, so you don't get mired in irrelevant sidequests and trivia

- experience exercising judgment, so you can survey alternate approaches and pick the one most likely to succeed

- experience learning, so you can come up to speed quickly

- wide experience, so you can apply lessons from your history in the new context

Take the notes, then go back and research them. Figure out what a minimal project in the new domain looks like, and do one quietly. Familiarize yourself with the tools that the new company uses.

Read research papers, technical journals, and all the in-company documentation you can get your hands on. Attend new engineer training sessions.

Figure out what the schedule is for your group(s) and dig in.


Some of your problems seem more like "new company" problems than "fresh domain" problems.

I have done a few major switches over the course of my career.

  Java/R&D -> MUMPS+VB/Medical -> Java/Legal -> C#/Military
The biggest problem was seeing that the common element over those multiple domains is that nobody really knows what they're doing, and everyone is just faking it so hard that it somehow just works anyway. So if you have any genuine competence in anything, you just copy everything that makes even an iota of sense from that into whatever else you're doing, and that makes you an instant genius.

You might have a different experience if you are in a hot spot where everyone around you seems to be smarter than you are, but in other places, the person that has been continuously learning new things on their own initiative for 12 years will catch up within 1 year or less, and will be jetting past everyone else by their second anniversary. The downside is that they will be bored by the third year, and looking elsewhere for promotion opportunities by the fourth.


> The biggest problem was seeing that the common element over those multiple domains is that nobody really knows what they're doing, and everyone is just faking it so hard that it somehow just works anyway. So if you have any genuine competence in anything, you just copy everything that makes even an iota of sense from that into whatever else you're doing, and that makes you an instant genius.

This is sooo true. From my experience most organizations and teams are very low performing, speaking about older companies, especially ones that have had rounds of layoffs or lots of turnover over the years. You truly get the "don't move my cheese types" who are just there because they're to lazy to find another job.

Mostly, the people who really knew the code/domain left long ago. Occasionally you'll find an old BA who ought to be running place, hunkered down somewhere. These people are gold.


You may want to clarify whether your issues are with the tech stack or the domain or both; they raise different issues. I think of the tech stack as the programming language you use as well as the major libraries/frameworks/services involved, while the domain is the area of business the software serves. So if you went from being a VB6 developer for a bank to a python developer for a health care company you switched both tech stack (VB6->python) and domain (banking->health care). Some info on how long it's been since the switch might also be helpful for gauging reasonable expectations.

Some specific thoughts:

2. Going the management route might work if you have domain knowledge but lack experience with the tech stack. If it's the other way around this will be a much harder sell in my opinion. Either way, don't be looking for a promotion unless you've been there at least a year, or there's a pressing business need that putting you in the job would neatly solve. They hired you to do a job, they're probably not going to react well to you immediately trying to get a different one.

3. I wouldn't sweat this one. Real time collaboration is going to be the hardest given a knowledge gap, but the real work of design and coding can be done very effectively while conducting research to fill in knowledge gaps when you need to. Your company and colleagues probably care more that you produce high quality code fast than whether or not you shine in meetings.

4. I think it's reasonable to expect you'll be pretty behind on tech skills for the first 3-6 months. If that's the case, I wouldn't sweat it, you'll probably catch up. If it's been a year and you're still behind you might be in trouble, it's time to find a new approach to learning what you need to learn. Domain knowledge on the other hand is a much slower slog. It may take 5 years to get to expert, and I don't think there are any real shortcuts.


Given the audience on HN, you could probably be a bit more specific about the old/new domain and get more relevant advice.

Just a thought!


100% this. One thing is to move all your stack from C# to F# or Haskell and another move from Angular to React.


I was thinking more along the lines of "I have 12 years of experience writing SaaS apps, and now I am working on firmware for embedded devices".


And here I was thinking along the lines of "I have 12 years of experience coding random crap, professionally and otherwise, and I'd like to go into biotech or somehow contribute to NewSpace industry".

(Which is exactly what I'd love to do.)


Domain means more than changing technologies.


My answer to this is: Do what you love.

This might mean to radically change what you do.

The vibe I get from your post is that the situation you are in is the result of a "career move". Driven by rational thinking about salary and future safety.

If your goal is to live a happy, meaningful life, I am sceptical that this approach can work. But I am very open to discuss this.

Personally, being raised very anti authoritarian, I naturally always did what I loved doing or what I was curious about. I'm not super rich and I don't jump around in joy all day. But I have a pretty nice lifestyle that I enjoy.

Would love to hear other perspectives on this.


Dear TekMol,

We regret to inform you that starting tomorrow, our organization, our parent company, our subsidiary company, and our affiliate partners will no longer be able to provide you services.

Unfortunately, all of our employees read your post and they agree with you and they have all quit to follow their bliss and have left en mass for Chiang Mai until they can "figure out what that means."

Candidly, we expect a large increase in the number of people working as life coaches.

As a result, we will no longer be able to provide the following services:

- Retail employees to help you - Any sort of clerical work - Coal mining and other energy gathering work that requires outdoor and or physical work - Water plants and filtration systems - Less glamours medical care - All the law jobs you don't know about but which keep our world running as well as it does - And any and all sundry job that aren't cool enough to be in an TV commercial

By this letter, we formally requests you stop spouting your bullshit.

Further, we encourage you to consider the implicit flip-side of your argument that, to paraphrase, one can only be happy or have a meaningful life if one does what they love. The incredibly insulting inference being that people who don't do exactly what they love can't possibly be happy or have a meaningful life.

Good luck with your parakeet farm or whatever it is you do.

Cordially,

The Good People at JustTryingToMakeRent Co.


Dear JustTryingToMakeRent employees,

Thank you very much for your open letter! And thank you for making the world such a wonderful place where coal is mined and plants are watered and everything works so flawlessly.

Is it really impossible to love those jobs? I often have the feeling that at least some of you are in a great mood when I meet you at your workplaces. For example when I visit my dentist. The whole team is always in a great mood, making jokes with each other, being friendly, enjoying the workday.

If there are jobs that simply cannot be loved - I think we should enhance or automate those. Let's start the debate. What job is nothing but shit?

I don't run a parakeet farm. I object to the "use" of animals. One of the things I love to do is write software though. Right now I am sitting in a nice internet cafe. At a window that overlooks a river. Sipping coffee, enhancing an application. And right now I love it. Chances are good that some of you are users of the application.

Yours, TekMol


I must say I was thinking doing what you love matters but I do what I love now i.e. designing infrastructure but it gets overwhelming, I don't like being forced to work when I don't feel. So I have decided to make more money asap and retire do what I love later. I really changed my path after reading 16 ways to fail book. Though many won't agree here, I think financial freedom is basic to live and do what you love.So i started looking at the career as job sometimes even as a task. And the task fetches my salary no more no less. Not working beyond 8 hours and not pushing projects for sake of management helps to tolerate the job even if you don't love it. Because then you have life beyond you money fetching task.


I totally agree! Especially with your point that we CAN radically change what we do and its really not that difficult to learn new stuff. People are great at learning new stuff. There are more hurdles with convincing other people that you can learn though..

I would love your help on a dilemma - how do you get past the practical hurdles of recruiters and "X years work experience reqd" & background & credentials?

Like I have an interest in ML and a very solid understanding & passion for math. I have picked up a bunch on my own and I'm sure i can pick up the rest - its mostly just linear algebra / statistics. But working data scientists tend to be grad students/PhDs and have some credentials to prove they are "academic" (because the rest of us could not possibly be "academic".. LOL). How do I get past that?


    how do you get past the practical hurdles of recruiters
    and "X years work experience reqd" & background &
    credentials?
From my experience, when you do what you love the power is completely on your side. Not on the side of recruiters and employers.

Companies have been hunting me down and trying to convince me to work for them for years now. Every company craves people who build great stuff and are passionate about what they do.

Shift your focus from what you get to what you give. And everything will fall in place over time.


It sounds awesome have a fully articulated sense of purpose such that a person can simply decide to focus on what they love, even if it's "radically different" from what they're doing now. How do you know whether what you're doing is truly what you love, once you eliminate meaningless rationalizations like "future safety?"


    How do you know whether what you're doing is
    truly what you love
My emotions tell me. Sometimes I feel dead and the world seems grey. And sometimes I feel so alive and the world is full of colors. The "alive" mode is the one I want to be in.


Emotions fluctuate all the time.


Do they fluctuate randomly?

I would think they are within the realm of our control.


I've done this most of my career. There is some great advice already in comments here, but if I had to boil it down to one thing, it would be this: have permission to be the new guy and ask dumb questions.

Explicitly ask for this permission -- and take advantage of it. If done well, yes, people will drop their opinion of you for a week or two. Then once you "get your feet wet" you'll start making a sythesis between what you already know and the new domain. It will start making sense to your coworkers.

Don't soft-pedal it. Don't try to know everything. In fact, admit to being a complete noob. Starting at zero you can humbly begin to kick ass and get noticed. Walking in the door as Superman? Not so much. If you do that, there's nowhere to go but down.

The crazy thing I've noticed is that people inside domains view technology as the most important part of a job. So instead of learning SexPumpkin 4.0, they'll look for somebody who's already an expert, because that's what we need!

As it turns out, there are a ton of super smart people in the world, but there are only a tiny few people that know both tech and the domain well enough to solve problems well. If you're too busy, lazy, or incompetent to pick up the new tech, then fresh meat isn't going to help. The real skill is to already know a bunch of things people want and be able to transition domains quickly.

You can gain that kind of thing by doing charity work, alongside personal projects.

One of the unexpected benefits of being the new guy and asking dumb questions is that in many cases, you end up solving complex problems that have stymied the org for years -- mainly because they've been so deep in the work they haven't been able to look at it from the outsid.

The worst thing you can do as a technical expert is to ignore this advice. Ask questions. A lot of them.


All great advice here. One other thing to consider is if the roles were reversed. What if you were still in your old field and a new senior member joined your team? She has 12 years of experience, but not in the field. What would be your expectations of her?

You'd likely expect that it's normal for her to take time to gain a bunch of context about the area. I promise you your coworkers feel the same way about you now.

Take the time to ramp up. No one is expecting gigantic impact from a senior person in their first three months.

Good luck.


I speak from my experience as a contractor in the telco domain, whereby there I would work in some industries I had no clue about. For example, I once worked in health and had no idea about the amount of regulations they had to adhere to.

However I realised they had accepted me because I was an expert in telco, not health. Similarly, I suspect you were hired because of technical skills and not because of your lack of experience in their domain.

As such, I learned the skill of saying "Can you just explain xyz, please?" in a direct and confident way. Context matters, of course. I wouldn't interrupt a meeting. But there's a time and a place.

Hope that gives you something to think about.


1. Act like you belong there. If you internalize the idea that you're a bit behind everyone (esp for your age), that you don't really "get" the tech, etc, etc, then your demeanor will reflect that and people will pick up on it; humans, even nerds, are social animals. If you're feeling especially insecure you should reflect on why the company hired you in the first place, and what particular skills or aptitude you bring to the team, and why that's valuable. If the answer to that is, "I don't know", then you're probably at the wrong job.

2. Not talking in meetings is generally something that other people notice to the extent that you should be talking but are not. Without knowing the details of your particular situation (eg, maybe within your company's culture it actually IS a big deal that you don't talk in meetings), I would say that if doing your job requires you to be active in meetings in which you are currently quiet, fix that. If this is a case of you feeling insecure because you feel like others are fitting in better / earning more brownie points / etc, I would posit that this is something that you notice a lot more than others do, and advise you to keep your focus on being good at your job rather than comparing yourself to others.

3. If you want management responsibility, I would suggest the following: a) ensure you are seen as a "set of safe hands" who knows how things work (tech and company processes) and can be entrusted to get stuff done and b) ensure that your manager and peers see you as a competent communicator. Once you are confident that a) and b) are both true, initiate a conversation with your manager about what type of leadership responsibilities you'd like to assume. If both a) and b) are not true, you shouldn't be angling for management roles.

Good luck!


Make sure you understand the basics of the new domain extremely well. You don't need to know everything in depth, but every piece you do know needs to fit together in your mind.

Ask questions until you think you understand, then have someone confirm your understanding. Those with experience in the domain will be able to recognize the right questions being asked.

In my experience, most seniors in a company are willing to help you get up to speed if they see that you're actually trying to understand the domain as opposed to just learning enough to get by.

Even though it seems like everyone else has a good understanding of things, this is usually not the case. Often people have bits and pieces of domain knowledge, but not a thorough understanding. These are not the ones who can really help you.

Find someone who has a good understanding that you seem to get along with. Be proactive and ask them if you could pick their brain over a long off-site lunch and then ask a lot of questions.


All I can say that sometimes I feel the same.

You have to accept this: you're at the mercy of your managers. If they hate you then you have no chance, OTOH if they love you, then you don't even have to lift a finger and you will be just fine, even if you're slower than you'd expected. Managers usually trust people based on gut feelings. I am still yet to see a competent manager who can evaluate the skills of his subordinates properly.

Also you didn't mention why did you join the new company in the first place? You have acquaintances working there? The company looked interesting from outside? You had met some employees in a tech meetup/hackathon earlier? Now we can only make assumptions.

Also make sure that you know why they hired you! I can't emphasize this one enough. Many times companies hire experienced people to do mundane tasks under the impression that they will do the shit that everyone hates faster. If this is the case, then RUN!!!! If it turns out that the new company has no roles which an experienced developer could enjoy like leading a team, or participating in design discussions or being a product manager then it's again a sign that you should just simply leave.

One other thing: smaller companies have a flat hierarchy. So there is no chance to step higher on the ladder. You should also consider if this is the case. In small companies it might take years or even decades until you can advance in your career. That might explain why they didn't put you in a PM/TL role.

There is one thing that many people in the tech industry overlooks: there simply cannot be everyone a tech lead/manager. The earlier you join a company or department, the better your chances are.

Also, some companies have seasonal busy periods. If they hired you during this busy period you might feel higher pressure. This might ease by time and you shouldn't take it personally (and you can even ask if that's the case).


Study. Learn. Listen to what your more experienced colleagues say, even if they are half your age. Basically, do what interns should do, because you are an intern now. And be thankful that you are not being paid like one.


I've worked in a number of domains. My CV looks pretty unconventional. I went from telecomms, to renewable energy, then embedded electronics for instrumentation, a stint in academia, from there to high power radio and TV broadcast and now particle accelerators.

They are different industries but have the common thread of engineering with a heavy electrical and electronic bias. I think that is the secret, to have enough of a common thread and to bootstrap using knowledge gained from one industry to move to another. Also, systems analysis and problem solving generally transfer pretty well.


One time I was listening to Artie Lange on the Howard Stern show talk about how he got interested in watching sports. (This is related, bare with me). He said something to the effect of "You want to get interested in a local sports team? Fine. How much money is in your bank account? Ok, $1,200 in your bank account. Great. Tonight go put $1,500 on the Nicks game. You won't be able to take your eyes off the TV."

I'm paraphrasing. The point is if you bet money you didn't have on a game, your stake in the outcome of that game would be HIGH.

Your challenge right now is, you have no stake in the matter. I heard someone say one time (Tim Ferris?) that success is just about incentives. Again, poorly paraphrasing.

The point is; with the right incentives you can accomplish amazing things. When I was single and dating, I was funny, charming and generous. The incentive there was obvious.

So how do you incentivize yourself to learn a new technology? Easy: create a situation where you MUST learn it. How? Sell (or promise) a project that includes finishing something in the tech you sold (or promised).

I would pick something that is slightly outside of your comfort zone, not WAY outside. The more you must get something done, the more you'll learn. You'll learn fast if you make a habit out of it.

Sometimes you can do it with a passion project too. So pick something that is important to you personally and just pick the tech you want to learn.

Programming is hard, the passion will carry you through the really hard problems.


I won't say the advice is good, but it's interesting at least.


At my company I find the culture mildly frustrating because we do so little to educate the new hires. Our method is to hire experience. So we now have a group of 25 design/engineer level people with a variety of project methods and a ragged list of skills. Because of this we can only accept small to medium projects. We would not be able to execute a large project because we don't have a large team, we don't have a uniform background or uniform method.

In my first engineering job there was training path and there was a "company way" of doing things. We hired all levels of experience and trained them on the skills and the company way as needed. I know a predefined method of project execution can be stifling, and that sometimes happened, but it was a good place to start.

At my current place, a person can roam the halls or chats and ask questions, but it is just too random. If someone is not delivering up to expectations, the engineering manager will visit tell them to improve. That is not what I call training. While it does work, somewhat, those who survive it simply reinforce whatever method of execution they develop in their own heads. The company grows by adding a small revenue stream, but not in the ability work together.

Finding your spot, developing your skills, learning your domain are mostly your responsibility. When you say "jobs were far to come by in my old area of expertise" that implies you are now in a better area to find a company more suited to you; maybe a more mentoring company. I agree with so much of the advice given to you so far. I will be working on myself using what I have read here. Some of the advice, however, was targeted at the time before you changed jobs. That is still possible.


Depending on your colleagues it might be totally fine to sit mostly silently for whatever time period you need until you start feeling you actually want to say something. The colleagues probably know your background, so they know there are large gaps in what you know about your current industry. Staying silent is at least better than desperately trying to speak of something you don't know about, IMO.


Agree. Give the process time. Many people are not very patient with trying to explain things that they consider obvious due to their experience in an area. This slows things down for someone who's ramping up. But over time, you piece things together and get to the bottom of things.

Also, if you ask a question and it gets shot down, you learn something from that too. You have to figure where the edge is before people start complaining.


Staying silent is at least better than desperately trying to speak of something you don't know about

I don't agree. You should obviously not attempt to make it appear you know something you don't, but asking questions is a great way to show that you are thinking and trying to connect your previous experience to the current context.


All four of your numbered points are about ego and politics. If that's what you're thinking about, worrying about, and spending time on, that's (ironically) the reason for all four problems. What are you doing to learn the new technology?

You're an expert in some ways and a beginner in others. Now that THIS is your job, you're a beginner in more ways than you're an expert. Act like a beginner does, ask lots of questions, learn the hell out of the new stuff, take notes like you already do and then follow up on them later - look up every single word or concept you don't understand.

Don't believe you should be "having input into things" in meetings because you shouldn't, you're a n00b. Listen and learn like everybody does when they're new on the job.

Don't let colleagues or superiors have "expectations" that were probably unrealistic all along. You need support, and time (mentoring possibly too, but mostly time, if you have a modicum of initiative), to learn what you need to learn. You're not going to be "productive" right away. If anybody hired you under any different expectation, they were mistaken and now need to be corrected. If you had any different expectation, you were deceived as well. If you sold yourself as an expert, that was only partly true. Come clean now. If anybody feels it was not a fair deal in light of this new understanding, then you should offer to end the deal i.e. resign.

If it feels awkward to suddenly change your behavior, you can make an announcement: "I thought my experience would serve me better than it has, so now I realize I'm a n00b and will commence to bother you all constantly with n00b questions." I guarantee the humility and the request for patience will result in a truly awesome outpouring of support. OR, you work with douchebags and should resign.

4. When I see guys half my experience are miles ahead of me in terms of the tech skills in the new area, I wonder if I even have a chance catching up ?

Yes you do, but these guys are not "half your experience" if they are miles ahead of you. If you played hockey 20 years, you'd understand a lot about teams, athleticism, and even the general principle of moving an object down the playing area toward a goal, as a team. Basketball is like that too, but since your basketball experience is 0, you'd still be worse at basketball than someone 19 years younger than you who played basketball for 1 year. And actually, you won't "catch up." All you can hope for is to have one year of basketball experience after one year.


I can only help with 3 and 4, but I'll do so.

I've only been in the industry for about 5 years, but I've swapped company almost every year. When you're a junior, you rarely have the luxury to re-use the technical knowledge from one company when you jump to the next one. You'll carry with you the general development learnings, but specifics about platforms and domains are kind of thrown into the brain garage where they'll stay until you make an effort to dig them out.

Now, you're not a junior. You have 12 years of expertise. These are worth a lot. Even if your specifics might not be as relevant you still have the general learnings. Of course you're not the best guy around when it comes to an area you're new to. Why are you setting these expectations on yourself?

> When I see guys half my experience are miles ahead of me in terms of the tech skills in the new area, I wonder if I even have a chance catching up ?

When it comes to your insecurities about this, just take a deep breath. You'll catch up dude. Everything's a process. Patience and persistence is all that's required.


Consultants deal with this constantly. Most in my company change project every few years. New customer, new domain, new technology etc., and we do just fine. I think it's the mindset, is it your expectations you're not meeting and not theirs?

Anyways, common for consultants. I think searching for consultant-material would be what you're after.


I'd add that at some point you want to discuss this with your manager. It might be entirely self imposed. Try to figure out if they are displeased with your progress thus far. Your colleagues think they should have hired someone with 12 years experience in this domain. You manager knew they would need to invest in you before you reached the level of your peers, even those with less overall experience. So long as your managers are happy, that's what really matters.

I'd recommend you form deeper relationships with the peers so they are helping you learn. Let them know you value their experience and they will be more likely to help. Constantly remind them, in a passive way, that you are learning. It sounds like they are competing with you, and you want them to be helping you. This will happen much better if you drive it. If you have to, get management involved, but that has it's own down sides and risks.


About a year ago, I switched from full-time Java development (15 years, mostly server side -- some Swing) to full-time Javascript development (React at first, then Angular) with all of the mental anguish that the amazingly arcane world of modern Javascript entails. I did have a little bit of a leg up in terms of previous html/css experience, but other than that it was a whole new world.

It seems to me that there is no other way to go other than full immersion and feeling really dumb for quite some time. The thing is though that you really need to depend on an unshakable faith that you will eventually come through the other side. You need to be firmly convinced of this. If not, convince yourself. It really helps to have done these career pivots before (which I have) and that may be the best thing about being an older developer. I know that there is nothing that I cannot come to grips with given time and effort.

Some hints:

Never pretend you understand something unless you do. Always admit "I don't know that" rather than fake it. This rule can be bent for small stuff that you are going to look up when you get back from your meeting.

Take notes (which you seem to be doing already). This is what you will google when you get back to your desk! ;D

Have a really understanding tech lead. Of course, I realize that this is just luck and a crap shoot, but working with great teachers and humane people is always best.

Have faith in the fact that the problems in your new domain are largely (probably) problems of computation that are generally applicable in ALL programming domains. Look for patterns that you are familiar with, like: what are we actually doing here? Reading some data files, transforming the result and storing them somewhere else? Oh! It's ETL! I know this. Ignore the weird jargon and get to the heart of the matter.

Give yourself time to feel like a dunce. You aren't, it's just gonna take time.


Define what "catching up" means. If you are like me, you have some idealized version of an expert in this domain, and you may or may not have the right idea. What does success mean in this field? What does success mean in this role? Often times we set the bar impossibly too high, and it makes us procrastinate getting started even more. Set a relaistic goal after researching and conceptualizing what "proficient" means, and break up how you will get there. Believe in the law of serendipity -- lady luck favors the one who tries. By even doing this you are already succeeding. You have my fondness. I hope it works out well for you because I am sure we will all need to do something similar at some point in our lives, especially when the big AI monster comes and eats all our jobs. (last part is a little facetious)


I belive the transition to the new domain - that the new company knew about very well - should be assited by the right tasks to learn. To learn! - which is something we do day by day even by hanging on to existing domains: we miss and we fall. The process of learning will uncover the parts we can ask about. To ask! As others already mentioned: asking helps. Assuming you know what to ask. That's where the learning process helps itself: uncovers dtails and further topics to ask about. Asking includes not only people but information sources like Google and Wikipedia - and the kind you will discover on your own as relevant one to your domain. To me usally the process of learning the product first as a novice client on a basic level is the best to start with (ideally joining an introductory course). Not being sad if half of it is in greek. Remember the greek part as something to study next. Then - or maybe instead of it - receiving important but many times neglected tasks of documentation and testing, fixing outstanding tiny problems also helps. Carrying out these gives the satisfaction to be useful and so boost confidence, which in turn helps asking 'silly' questions. Newcomers ask silly questions, this is a fact, no way avoiding it and should not be avoided since these show lack of fundamental knowledge that the newcomer do not posess yet. Still newcomers afraid to ask because they lack some confidence (at least I do in such situations) so anything that boosts confidence a bit is a huge help. So small but important tasks might help a lot. All this is impossible without the assistance of the domain experts and the experts of the company culture (since the answer many times is not in the logics of the domain but in the culture or even the history of the particular company). It should be accepted that your initial pace is slower due to the requirements of the domain and company switch that comes with things to process. I believe the situation should be discussed honestly with the superiors as the least. They are as interested in productive work as you are and they may not have that high expectations for this period as you may think (being aware of your transition).


At a certain point you have to crunch, but you should take notes but also share your notes. Present lists of questions from the notes you took last time and show off the fact you are trying to catch up. The most frustrating thing to a lot of teachers is people that nod along and then ask the same question next week.

Also another good thing is to dig and ask around for older documentation/simpler versions. It is a lot easier to sometimes work at the task at hand if you can compare the naive version to the one with hard-won fixes. Sometimes the simplest explanation for what you need to do is the first few times the idea was pitched, not where it is now where that is an accepted norm of knowledge.


One bit of advice that I learned in art school and think applies to all sorts of learning is: "Work general to specific". When painting, you first block in large sections, then break those down into smaller sections, smaller and smaller until you arrive at the level of detail you want. I'm now a software developer, but take the same approach when learning a customer's domain or a new language or framework. I first get the "big picture", then break that down further and further by reading, asking, and listening.

Re number 4, yes, you have a chance, unless you got fired today. Have the attitude that you can and will learn this domain and quickly become an expert.


I've found that subscribing to SafariBooks for a few months and reading through material relevant to my new domain to be useful. That said, where you're really going to shine are areas in your new domain that overlap with your previous domain.


Didn't know about SafariBooks. Any course / material you really liked or recommend?


safaribooksonline.com is the monthly rental version for O'Reilly's books. I generally stick with the O'Reilly books, and avoid Packt books like the plague. The case studies seem to be hit or miss. I haven't tried the videos yet, although it looks like that's where they're doing the most work.


Search for areas of opportunity where you can make an impact with your current skill and grow from there. There are gonna be pockets of opportunity your org can't attack just because there is too much to do.

For example, I was a finance guy who switched to tech. Was the worst student in my programming bootcamp. Got a job and found a niche in testing. It met the company's needs and my skillset at the time. 3 years later I'm still not as skilled as other geniuses miles ahead of me but I'm doing great, work is great and my salary is top of market for a lead engineer.


1. Commit to starting over and learning with fresh eyes

2. Don't rely on old knowledge or pedigree as a crutch

3. Humble yourself to your colleagues and ask questions

4. Seek out mentors with the expressed purpose of learning

5. Understand that new beginnings take time and purpose


I'm doing this right now - Video to MES (manufacturing.) This isn't unusual at all - you understand the value of domain experience so do the things that will make you an expert.

1) Give training sessions to those who are also new. It will force you to learn the software. 2) pick up pager rotation. Supporting the software will force you into new areas of the domain.

Those are the things that will get you there fast. It's scary and hard but just wait 6 months to a year or so and you'll be effective. Any new domain that is sufficiently interesting takes a long time to get into.


I think it's important to stay up to date on technologies/fields outside of your area of expertise so that the eventual switch to another domain is less of a complete overhaul for you.


1. Complete most your tasks on time.

2. Complete all your tasks on time.

3. Come up with new ideas related to your domain.

4. Implement at least one of your ideas.

If you manage to do that within a year, you'll be a good asset to your team at any given point. No one will excpect you to start at step #4. Be humble and keep asking questions until it's clear in your head. The tech world won't change tomorrow, cold, big ego, etc. though, time is your friend in this case so just be patient and follow those steps.


I have done this few times and for me doing a side project in the new area always helped. Few other ways: - online courses - books - take notes, but do read up about them - see if the new team has a 'new joinee getting started' kind of document

Lastly I strongly recommend letting everyone know you are new to the domain. At the min. it will set expectations and usually you will get pointers.


I worry about this sort of thing often.

While I don't have as much experience as OP in my current domain (Which happens to be the mortgage industry ~2 years) I still have the same feelings.

Whenever I would want to get a new job elsewhere I _hope_ that all of my knowledge isn't too domain specific to the point where it doesn't help me later on.

Any extra tips would be appreciated.


Learning is social. You can pick up a lot "telepathically" (i use this word loosely) by just spending time with practitioners. They can give you the proper orientation and guidance. Just remain open, humble, courageous, empathetic, and persistent!


Very good advice here. I have done it twice. The first time around I grew fast and was happy. This second time I am unhappy as the organization is slower, less nimble and very little room to grow and learn. I hope you will have luck with your choice!


Just wait for your turn. Spend more time than others. Start with one initiative or issue and see it to the end. Focus on one thing at a time. You seem to be overthinking. Such initial hickups are common. We all have gone through them. All the best


Here are some things I've found helpful:

1. Most importantly, set your own expectations correctly.

No matter how you slice it, switching domains after years of experience is going to be tough. That's not to say it isn't the right decision, or won't be incredibly rewarding. It's just going to be challenging. I've had more personal success in these scenarios after accepting that fact, and not being so hard on myself for the ramp-up time.

2. Identify people with expertise, and talk to them.

Don't get stuck in a research/reading rabbit hole. It can be tempting to sit back and try to replicate your prior expertise by reading/studying your new domain. Rather, find people you identify as experts and talk to them. Learn from their experience. Chances are it is your experience that made you an expert in your last domain, so do your best to learn from those with experience in your new domain.

I hope this helps!


Identify that one person in your company who has both:

- Knowledge of the domain

- Ability and willingness to explain things clearly and succinctly

When questions come up, ask that one person, in private. Some of your questions will be:

- I think I need to learn X, Y and Z. Which should I learn first?

- How do I learn X?


Can you give us more detail about how different the two domains are?

I assume it's not something like switch from web development to mobile or to dev ops. Something like from programming to data science or quant analysis?


Start afresh by addressing the issue of your experience with your boss and setting expectations based on your current experience.

If that doesen't help, look for a job elsewhere.


You biggest advantage is your ability to learn. Don't be afraid to start learning the basics of the new domain.


Sorry, to be clear, is there an actual (e.g. performance review?) problem, or are you just feeling imposter syndrome?


It depends, if this new field is something growing, something with a perspective (eg ML, crypto) then keep on. Your insecurity will be your biggest motivator pushing you to the limit. In one year you will be better than your peers.

If this field isn't trending (eg VBA, print) then just look for another job.

In other words: Can you boost your personal market value with this job in one year?


What is the particular domain?


You sound like me.

All I can tell you is to fake it til you make it. It doesn't take that long before your lack of experience in the particular subject at hand ceases to be the limiting factor.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: