Read the documentation. Aggressively pursue opportunities to learn new skills.
I feel like your advice is not emphasized enough in tech circles. Our field is constantly changing and evolving so success is often predicated on willingness and eagerness to learn.
That said, also recognize that not every new skill or tool is necessarily appropriate for a particular task. You should still learn them, though, otherwise when they are appropriate, you may not even recognize it.
Get a better paying job once you've got some experience. Raises won't keep up with your value.
Don't work yourself to the bone. There really are plenty of jobs that only require 40hrs/wk and pay the same or better.
Work somewhere with a good culture.
3 and leave is the general rule of thumb till you’re at the most senior levels. Never move laterally if it can be avoided, know what the resume and experience looks like for the next level and always be working towards that.
This is extremely important. Your best raises and title changes will come from changing companies, not internally.
After a number of years with my first company (a household name), I quit and got an 80% raise. Based on how quickly my new company accepted my salary request, I'm pretty sure I could have asked for more.
Don't burn out! Ask for help and guidance when needed, and take care of your mental and physical health (get a hobby, go out with friends, go to the gym, etc.)
I've seen brilliant people burn out and end up leaving/missing out growth opportunities because of it. Now that I manage people, it is my biggest area of focus because many times the best employees are the most at risk. They keep getting praise and asked to be involved in more and more and it becomes hard to say 'no' to new projects, responsibilities, etc... Until it is to much.
When it happens everyone looses, your boss, your team, the company, and especially you.
a million times this, so many young people overwork themselves and burn out quickly
I cringe whenever a see someone has checked in code at 1am on a weekend, and these people are also working normal business hours so it’s not like they are only working at night
sadly it’s usually the same people who never take PTO either
What if my whole problem is I don’t know what I need or what kind of help I could use?
Whenever I work a job that’s too complex for me, part of the problem is I can’t clearly define what the heck is going on to even know what kind of thing would help.
It’s like my brain just start blanking out.
There is no one perfect solution unfortunately.
Meeting a therapist will definitely help to identify the root cause, and eventually will help.
I think the root cause is the complexity. I do a lot better in jobs where the situations might change but the rules don’t. In programming, everything is changing all the time and I can’t keep up. There’s no repetition and if you are repeating yourself you’re doing it wrong.
I need parts of the day when I’m not being creative within a formally strict environment. It takes too much processing power for my brain to do that, and it overworks me.
I know the root cause and the problem is solved because I’m working jobs that have complexity within the range I can handle.
I think the root cause is the complexity.
Split the problem into manageable chunks, then attack the chunks. Apply recursion as needed.
This is part of a more senior skillset, as some times a senior will be breaking up the problem and assigning the smaller pieces to other devs.
You're not responsible for the bad decisions made by the people who have positional authority over you. Do your best. Warn them about the risks. Let yourself feel disappointed by their decisions, but don't ever accept responsibility for them. If you did your best to warn them, then you took your responsibility seriously. That's enough.
CYA in a nutshell
UPDATE: I added some clarifying points in light of getting some of this wrong. I believe the underlying point still stands.
No. I believe I understand why you think so, but just no.
At best, covering your ass means gathering evidence about how much you tried to warn the people making decisions, in order to avoid or deflect blame when things go wrong and someone starts wandering the countryside looking for people to blame. I'm not suggesting that. I'm not even suggesting saying "I told you so." when things go wrong.
Quite often, at least how I've seen it, covering your ass involves not even trying to do the right thing or, perhaps, pretending in public to do the right thing in order to have a plausible excuse when things go wrong. That's also not what I'm advising.
I'm advising not to accept responsibility for other people's bad decisions. If you genuinely did your best to influence their decision and they chose poorly anyway, don't take responsibility for that choice. The responsibly remains with the person who had the authority to decide.
For example, if the OP decides to listen to you instead of to me, that's not my responsibility. I've tried to explain my position, but the responsibility for choosing what to believe belongs with them. I'm most definitely not covering my ass; I'm recognizing that I'm not responsible for replacing OP's judgment with mine. If they ask me for more information, I have the responsibility to provide it. If they ask me to clarify my position, I have the responsibility to do that. But I am not responsible for convincing them nor for their final decision.
Covering your ass typically involves not trying to do the right thing or, perhaps, pretending to do the right thing in public in order to have a plausible excuse when things go wrong
You have a very different idea of CYA than I (or the other poster). To me, CYA means ensuing you have evidence that tried to do the right thing and were overruled, so that you will can (justifiably) avoid repercussions when the failures you warned about come to pass.
I'm with you. Two things.
One, I assumed that the commenter was referring to the cynical kind of CYA, which I was certainly not advocating. I might well have got that wrong; only the commenter knows what was in their heart. Oops. I've tried to clarify my first comment, just in case that helps anyone else reading.
Two, I said nothing about gathering evidence to be able to produce when needed. (And I genuinely wasn't thinking about that.) I merely said that if you tried your best, then you did enough and not to feel responsible for their decisions.
In both cases, I don't think I suggested covering any ass. I certainly didn't intend to.
Thank you for clarifying and not letting me off the hook.
Exercise regularly. Maintain good posture. Stretch. It kills your body, working at a computer all day.
Above all else here, this.
If you're a developer, read the source code. People will tell you how they remember things working, or how they think they should work. The code is what it is.
I don't know if that's obvious for people entering this profession but mind that you don't read code like a book. Check how the functions you use are implemented. What's being called from where (call stack helps in the debugger). How are experience programmers managing their code etc. It's a good skill to learn how to navigate other people code and quickly find the parts that matter
Exactly! Always push for code pointers for everything people tell you about the codebase. Even if the code has a bug and isn't working as intended, it's so important to know the actual truth if what's happening.
Understand that technology cannot fix people problems. Always remember that. If you're asked to solve a people problem and you don't understand it, you will suffer. Only management can fix people problems.
Also, it may not seem like it, but software is almost entirely about people. Everything comes down to the users. You need people to use your software. You need people to want to use your software. Even if your users are other engineers, you still need users. You could build the best piece of software ever made, but it's nothing without usage.
Things like marketing, product, and design are usually equal parts of building software.
This is something that took me a long time to come to terms with.
Yup. It's definitely always about people. The people using it.
I've worked in software support, QA, and technical writing.
A LOT of developers who come in as devs from the very start of their careers know very little about how the average person might interact with the software they are creating. And what they know of, they can (sometimes) be so sneering and dismissive of that it actually impacts their design decisions. Like, "I don't care, the user is stupid, I'm doing it the RIGHT way." Even when the "stupid user" is like 90% of the population that'll use your widget.
A new (and old) dev should read past customer tickets and talk to your customer support people, as they'll have the actual real-world experience and examples with non-technical users that can give you insight into how to better create the thing that you are creating.
To make a comparison...say you were a furniture designer making chairs, and you're 6'3". Sitting in the chair yourself and proclaiming it's fine isn't enough if your users are children, women, guys shorter than you, people lighter than you, people heavier than you, and the disabled. You need to actually understand how people who navigate the world in a different way than you do interact with the thing you're making. A chair that works fine for someone who is 6'3" with two working legs might be unusable for a 11 year old who broke their foot, or a 4'11" grandmother who can no longer move heavy things around (say if the chair is solid and heavy and something a 6'3" dude could easily move).
With technology, it means average non-tech users will flow through menus differently than you, might have vision or hearing problems that you don't have that make signals from the widget difficult to decipher, and people in general who are non-techie can also be more risk-adverse when it comes to things like clicking strange buttons. And that's just the tip of the iceberg.
Interesting, mind giving an example?
Trying to use technology to control people clocking in on time or making the IT department the company computer police
Oh I see! that is a great example, thanks.
:wq
Years of imprisonment avoided
:q!
I wonder how many files I've accidentally left that in while I wasn't in vi.
For me, probably a lot.
:x
I don't like that as much because it's not as clear what it does. I remember ":wq" as "write quit".
Everyone else here who said, "Keep learning" is right on, but don't forget to work on your soft people skills along with your tech skills. Whether your long term goal is to stay in development or some other aspect of the industry, you should be comfortable talking to all sorts of people (management, sales, customers, etc...), making presentations, being social at conferences and so on. We (techies like me) tend to forget this, but it's really important.
Imagine yourself starting your own company in five years or being the senior manager of a large group. How are you going to like meeting new people every day, selling or at least explaining your product or service to them? If the answer is "not very", then start working on that now.
Ask questions, don't assume. Keep notes of meetings, and notes of your work, little bits. Always have a good rollback plan.
Ask the experts from help, and learn from them. Don't ask things you can legitimately learn really easily on your own by just doing a quick read of the code, but the bar for questions to not be stupid is pretty low. In most projects with any complexity, it's probably overall saving the company money if you ask someone who knows and can save you time, instead of wasting a ton of your time reaching the same conclusion. But next time that problem comes up, you should know how to solve it, so it saves everyone time.
If you have an opportunity to learn a new platform or technology, take it. Every environment has a different way of organizing, implementing, troubleshooting, etc. Each one you learn gives you a new way to look at a project, and teaches you something about how other people may think about projects, problems, and solutions.
People who stick with the same tech for decades are also stuck with the same approach to new projects. When the only tool you have is a hammer, every problem looks like a nail, and all that. Get more tools in your tool belt.
Depending on your specific field tough.
In front-end there are so many opinions it becomes a lot of noise so you kinda have to narrow your focus.
If you're offered a job with more money/benefits or whatever, take it. Don't give your employer the option to counter. And if you ever do let them counter out of curiosity, don't take it... Leave.
There's too many horror stories of people basically staying on after a counter-offer, only to train their replacement and end up tossed out anyways.
Loyalty doesn't mean shit in tech; any promotion you get internally at a job will be pennies compared to what you're able to get by shopping around; so do yourself a favor and run whenever the opportunity arises.
YMMV; staying can work well but you really have to know your employer, and be able to roll with the punches either way. It can be equally risky to be the new guy again. Always have an honest understanding of your replaceability.
If you're irreplaceable, you're probably doing something wrong, at least in tech.
All technical fields especially should have a high bar for documenting what you do and how you do it, requiring documentation in every form and for every aspect. In my field, IT support/sysadmin/network admin, process, procedure, common fixes, system set up, network design, etc should all be documented. The only down side to having to replace me should be the long lead time for the new person to chew through the documentation to fully understand what's going on and how it's all interconnected, and not much more.
IMO, person to person "knowledge transfer" as my current employer currently implements, is unviable, and should not be allowed to be the norm. There should never be only one person at an org that knows the job, and the current state of affairs and why the current state is what it is.
If any org does have that single worker point of failure in knowledge, then they're just one incident with a bus away from significant risk of their systems entirely collapsing. I call this the individuals "bus factor", aka, if you're hit by a bus, how fucked is everyone else? An IT person's bus factor should always be low since almost all businesses are data management companies that make money doing X; everything from users Rolodex, to the CRM, to their communications and daily working tools, are almost always entirely dependent on IT, in some way, shape, or form. Less so for companies doing non-computer controlled manufacturing, but any desk job, or white collar office would entirely collapse if their IT staff was suddenly unavailable and their IT environment was to go down. At that point, just close up shop.
I don't think I agree with you, replaceability depends on a lot of factors, really.
I'm a lead dev who works mostly in test automation and dev ops. I can assure you that no matter how much and thoroughly I document and share knowledge (I've became known in my company for that since every piece of doc has my name somewhere on it lol) I can't see anyone around there being able to fully take the reins if something happened to me.
in my case, it's a mixture of talent crisis in the industry, lack of interest/expertise in the field and my own company's culture (that doesn't value these infrastructural subjects enough). I bet other people from different areas in tech might share different reasons
but all in all, being irreplaceable is hardly an employee's fault. if a company can't manage to lose an employee (or lets people get away without documenting/sharing knowledge) it's entirely their own fault!
I absolutely get what you're saying, and it definitely depends on a lot of factors, mainly how easily replaceable you are.
I agree with the fact that it takes a combination of talent, experience/expertise in the field, and the company itself (mainly it's culture) that can dictate a lot of that. However, things like previous experience, and talent are not exactly things you can pass on to a new technician via any form of documentation without chronicling your life story with every instance of needing to do anything remotely technical which may lean into the problem-solving skills and thought process you uniquely have, and even then, on-boarding that experience would be a monumental challenge. Simply put, that's not practical. Even that, doesn't account for any ability to pass on talent, which isn't quantifiable in any meaningful way.
The main argument I have is that the knowledge of the organization's systems, how they interconnect, why those interconnections matter, how they work, etc. should not be up for question or debate; and it should only be a matter of finding someone with relevant past experience in similar systems, with sufficient talent, who meshes adequately with the company culture, to be found, in order to replace someone.
Unfortunately, finding someone with sufficient talent is often the most difficult part, and since it's difficult to assess talent in an interview or even a set of interviews, it's usually impossible to know if someone is going to "fit the bill" so-to-speak, until they've been thrown into the fire.... This is the reason for the probationary period of most workers, both for the benefit of the worker, if they're not meshing with the company, and for the company, if the worker isn't capable of doing the job. Unfortunately, often, especially with I.T. work, it's difficult to know whether someone is going to work out long-term after a few months, especially when the amount of knowledge someone needs to have to actually do most tech jobs is so monumental that it's unlikely that the new hire is going to have any significant depth of knowledge in the technical systems within a few months of being hired.
All of this sets aside the factor that every individual is unique and makes unique choices and contributions to the whole, so even "replacing" a very replaceable individual position, isn't a 1:1 comparison, the new worker may be worse, or indeed, even better, than the previous one, but rarely, if ever, would perform EXACTLY the same in every circumstance.
My core argument is that the information about the system (which needs to be supplemented by talent and experience), should never be lost if an employee decides to walk (either by finding a new job, walking in front of a bus, or off a short pier). If that information is lost, it's a significant managerial oversight which allowed that to happen.
yep, agreed will all of that
in any case, I never been somewhere where this is properly done to the letter (from an individual's or managerial's perspective). not that I REALLY care tbf, I just do my part to the best of my knowledge and fly away hehe
I can appreciate that. I just think we were arguing the same points overall; and as demonstrated, there's a lot not nuance, not only to the idea of what "replace" means, whether it's simply having someone fill the role, or having someone do the same job at approximately the same efficiency and level of output, to what other factors may go into the job that cannot be transferred to newcomers by way of speech, text, or video.
There's certainly a lot to the discussion, as is the way with many things, but the amount you can help the next person by why of documentation, should always, ALWAYS be something that's baked into the job.
Hilariously, I advocated for better documentation at my employer, they gave me every excuse under the sun about it. I was only really asking "which documentation system are we moving forward with?" And got no clear answer. Work has ~4 different sets of documentation, all of which are in varying levels of being obsolete, irrelevant, or incomplete. I wanted to fix it and nobody could decide what to do, so I did nothing.
About two months ago, I hit burnout, and now I'm on medical leave. So essentially, I had a bunch of information that nobody else had, and I was incapable of putting it into documentation, either due to the uncertainty of where to put it, or the whole zero hours a week that work gave me to document things.... And then I was metaphorically hit by a bus.
Sucks to be them.
yeah. I have the feeling that this story is way too common. which is very telling of how much the system isn't driven towards innovation as many claim. we brag a lot about human ability to pass down knowledge via written language and turns out that most information passed down on some of the highest tech industries is done verbally or not at all! lol
Ultimately tech is a tool to help automate and solve people’s problems. You want to get close to the people your solving problems for so you can get feedback and figure out how to do your job. Your organization may not do this for you. I spend a lot of time on forums listening to my users, and do a lot of extra testing to make sure I’m solving there problems and not making new ones.
I can think of three big pieces of advice:
Are you sure? I think the golden age of the magic tech jobs is nearing its end. If you want to join the tech industry because it's an easy ticket for a successful life then you might wanna rethink that. If you want to join the tech industry because engineering is pure magic and you want to be a part of that, then by all means, you do you. Just be ready for it to be a bumpy road if you aren't able to adapt to whatever AI does to the industry over the lifetime of your career.
Find companies who will treat you right, and where people are real and do real shit. When I was first starting out, a project I was working on was behind. I stayed over the weekend, even though people told me not to. I finished, I was proud of myself. Then I came in on Monday and everyone else's stuff was behind anyway, so we missed our deadline regardless, and in the end it didn't matter. Right around that time was when I decided, more or less, to hell with this. At the company I eventually jumped ship to, my boss would regularly push back on clients who wanted us to work weekends, come by and encourage people to live a normal life instead of just a working-to-death life. Basically, he looked out for people. So I stayed there for quite a while. Basically, after that experience, if the boss wasn't looking out for me or the tech was shoddy, I bailed instantly. You gotta have a good human life and take pride in what you do.
Own up to your fuck-ups. You'll make some. I've destroyed important hardware, made massive architecture mistakes on client work which the clients then identified and talked to us about, deleted the partition table on an important public-facing server, you name it. When I did something like this, I would be 100% upfront about what happened. In good working environments, people would recognize and give respect for that, because nobody's perfect. In bad working environments, being upfront about mistakes would somehow be a bad thing (see point #2). The answer is not to become sneaky. The answer is to leave and go somewhere where people respect honesty. Those places do exist.
That third one can be tough, but I think it’s super important, and, not just in tech.
An easy way to confirm your first point: would you still want to do it if you were paid significantly less? If so, then yeah, you're in the right place.
Point 1 is pure speculation. You could say the same about any profession. Absolutely not something woth considering when looking for career opportunities. You can always pivot with your career and knowing how to code is a plus because that makes you understand tech better
Remember tech-companies exist to make money, not to "do good." Whatever problem they are supposedly working on, they are only doing it because someone thinks they can eventually turn it into a revenue stream. Don't drink the kool-aid, be a mercenary and get as much out of it that you can until you can leave for good. Dont' be the like the smuck's that are still working at twitter.
Yup, and this applies to any company. If you don't own the business, you are a line item, not "family". Always be ready to jump ship for a better opportunity, because they will do the same.
Don't be evil
Wasn’t that google’s slogan once
Yes but being evil pays better.
No more than 2 years in a same company and always be interview ready. Keep regular contact with recruiters. There’s always a better opportunity.
This is exactly what my friend did. He earns double my salary even though I work in one of those big companies and do more than just development.
Don't burn yourself out, document everything.
When interviewing, if a company gives you the "We work hard and we play hard" line, run. It actually means tons of unpaid overtime in exchange for some snacks and a broken ping-pong table.
Never stop learning. Most important advice IMO.
Tech is a field that is constantly evolving, whether you're a developer or IT service desk, the tools you use today will probably be very different 5 or 10 years from now. Never get stuck in a rut, it'll burn you later in life. Remain curious and keep learning the new things coming out.
^^^
Always be hungry to learn new things. Don’t get too attached to any system or process.
The best engineers are the ones willing to adopt and drive new tech.
Set boundaries.
At my first professional job, there was one guy who always came in at exactly on time and never stayed late. I always thought it was weird, I'd typically stay at least long enough to finish whatever thought I was working on, and sometimes later just because I had nothing important to get to. Eventually I became one of the guys to go to when you needed someone to stay late. I didn't mind, in fact I like being helpful. Looking back, I realized that I gave the company a lot of free work and didn't get anything for it.
It seems obvious but important to realize from day one, you are setting expectations. A "good" manager will figure out pretty quickly which employees they can exploit and how.
What area of the tech industry are you starting in? It would help to know so we could tailor the advice to you.
you will end up bringing down production or make a however many tens of thousands of dollar mistake. Don't worry about it too much when it happens. That sort of thing doesn't usually get you fired the first time.
Be transparent about your mistakes and learn from them - better yet, help make sure others won't make the same mistake.
Read the damn code
So many problems can be solved by just reading the code. A corollary to this: make sure the code you write is readable.
Another correlary: learn lots of languages, even if you’ll never use them. I never want to fall into a codebase that I’ve never even learned the paradigms. One procedural, one functional, one OOP, one interpreted, one compiled, one byte code compiled, one or two command line scripts, regex, all the structured data text languages: XML, CSV, JSON, YAML, TOML, … A JavaScript framework. HTML. A relational database, a non relational db. REST.
Should be enough to get started lol. But you learn something from each, about code architecture at least.
Always learn the languages preferred directory and repo layout structure, never invent your own.
Be hard-working but loyalty will take you almost no where. Every 2 years you should start looking for a new job with better pay and less hats. If you are a year in and hate it just switch to somewhere new. I got 2% raises at jobs year to year but switching jobs for me got 20% - 40% more.
Make things just complex enough that others don’t want to learn it but not so complex anyone can say it is too complex.
Also pick up tasks others don’t want to and make yourself hard to get rid of.
Then quit and get hired back as a consultant/contractor and work your own hours and how much you want to.
It can depend on the area you're going into, but things like continuous learning of new skills, as well as keeping up-to-date with the latest happenings in that field, are always good ones to do.
All other comments in the post are gold.
Always stay relevant with skills and knowledge relevant to the market - one day you work for papa Google and everything is great, another day you'll get fired without you seeing it coming - job is not a family.
It's fun and games to master a skill/technology, but if there are no jobs for that, that is a red flag.
Generally it's important to keep the hobby-job balance, and to understand that sometimes your hobby specifically won't be your job, and that is OK because most of the people are like that.
I’m looking to change careers into tech at 43. I’ve been a teacher my whole life but education is…just not a good job anymore. I’m very interested in data science and would love to end up working on climate modeling but I’m practical and understand that I should take what I can get. Anyone have some career wisdom they’d be willing to share?
Afaik (I'm an environmental geologist) Climate Modeling isn't really tech, or the tech industry, it's more academia. Most climate modelers I know of are working off grants in university labs. That may/may not help you get into it, but if you're seeking something that is a deviation from teaching/education, academia isn't much better for all the same reasons really.
Do you have a background in climate science or environmental science? Or modelling for that matter?
I don’t have a background in it. I’ve been a public school music teacher most of my career, but I’m also a lifelong nerd and the draw of making a difference in climate change using math has been just too attractive these last few years. In January I start online classes in statistics, Python, and data management/analysis from a local university. I don’t want to end up in a university lab though. I understand that breaking in in a new career will mean taking what I can get until I’m better experienced.
What area of the country are you in?
Water conservation and environmental protection are probably your best available avenues into a climate science career of any sort. I've worked in environmental since 2012 when I got my master's. I specialize in hydrogeology, but there are lots of fields. The problem you will run into is they are gated by credential barriers at a certain point - specifically PE/PG requirements. If you have the math portion you are probably well capable of passing the PE exam, you just need the experience and recs, so you may want to tailor your class load to put you on that path. Engineer's also generally have higher pay brackets so there's that little carrot as well.
Most environmental based companies, regardless of their area of focus, have modelers and need engineers of various backgrounds. You typically don't get hired into modeling, but can sort of steer yourself that way once you're established. I'd recommend you avoid environmental consulting - it does not sound like the work environment you're looking for, and most clients end up being polluters. Water Purveyors could be a really interesting target to aim yourself at. They do SO MUCH more than water supply, and they are constantly looking into all kinds of interesting projects. When your job is to supply an ever increasing population with an ever dwindling supply of a crucial resource, creativity is very much necessitated.
"what area of the country" 🙄🙄
You know there's more than one country?
I'm am absolutely positive that OP only lives in one country, not two or three. Do you think he lives in more than one? Or are you just surfing around trying to be pedantic?
Water Purveyor wasn’t even on my radar - thanks so much for that insight! I will definitely look into it. I did worry there would be some certification barriers that might be difficult to achieve either because of time or expense. I’m on the east coast, though, so not perhaps in an area where water conservation is front of mind for many.
As far as barriers, better to know where they are and how big they are now so you know exactly how high the metaphorical ladder you need has to be. All municipalities have water purveyors of some sort, but you're right in that they'll likely be less focused on conservation. They won't however be less focused on protection and they may still have beneficial use projects. Also that's not inherently bad news for you - it means a likely lower barrier to entry.
Anyways best of luck.
I did the same at about 43. Had some tech support background and could talk the talk, so that helped.
Got no solid advice, except to so it doable. And don't let anyone tell you coding is a "young man's game". That held me back for years. We got coders of all ages, beginners to near retirement.
That’s so good to hear!
Be patient. It takes time to "get going".
If you know how to program, you're in a good spot. If you don't know how to program, start with fundamentals.
SICP is good. It's Lisp. You'll probably never write a line of Lisp professionally, but it will help shape how you reason about solving problems.
Develop some solid fundamentals.
This sounds like a conversation for you and your manager. I've had a few with my team that have resulted in different solutions for different people.
With one we established a monthly 1h call for her to explain where she is stuck, what she has tried, and we brainstorm how to get through it. This is separate from our usual weekly check-ins and focuses on issues related specifically to complexity and ambiguity.
With another, he created a list of what she thinks needs to happen and puts together ideas on how to get through it. I review it and then give him feedback. He liked this as over time he built confidence on his ideas as my feedback more often than not was "exactly what I would try, go for it".
Finally, sometimes is about reducing the work load on that team member until they get a good foothold and slowly start adding more.
Shot answer, no one solution or easy path, but communication with your manager and hopefully a good manager is your besy bet.
Leave. It's all going to hell.
Here is what I did. I bought an IBM ThinkServer and put as much ram as I could in it (32GB; keep in mind this was 2015). Then I loaded it up Windows Server by itself and played with the Windows and its features. Then I loaded Hyper-V to play with virtualization and created my first domain environment, learning DNS, DHCP, GPOs, an Exchange Server, and VPNs. I ended up throwing a 4-port NIC in there and set up pfsense on a VM to act as my firewall router so I could learn VLANs, traffic shaping, and security. Then I put ESXi on there and learned vSphere and vCenter. You can sign up for an NFR key from Veeam and play with backing up a virtual infrastructure.
There is so much you can do. I started out on Helpdesk in 2015 and now I am a Senior System Engineer that works with the VMware platform all day. If you invest in yourself, it will directly invest in your future and how quickly the promotions happen, and the amount that the responsibilities increase. Feel free to reach out and DM me if you have any other questions that I could help with. Good luck to you!
Don't get overwhelmed if the task seems too difficult or complex. Take time to write it out on paper, break it down in smaller parts and tackle them in turn.
But... Also be honest with yourself if you're struggling, there's no shame in admitting that you need the help of someone more experienced.
Specialise in an area AI won't be able to do in five years time.
Do some study in your own time.
If you aren't sure what to do and like servers etc, just do the Microsoft courses. Having these on your resume gets you ahead of people that don't have them at all.
One of the best things a Senior Eng taught me was to understand and ask questions about every single line of code in a file you’re touching.
It’s daunting, and time consuming but the rewards are vast and eventually it will be much quicker. Of course it’s easier to follow patterns and make quick changes, but it’s more valuable to fully understand what you’re doing instead of suggesting changes that should work.
Read the documentation. Aggressively pursue opportunities to learn new skills.
I feel like your advice is not emphasized enough in tech circles. Our field is constantly changing and evolving so success is often predicated on willingness and eagerness to learn.
That said, also recognize that not every new skill or tool is necessarily appropriate for a particular task. You should still learn them, though, otherwise when they are appropriate, you may not even recognize it.
Get a better paying job once you've got some experience. Raises won't keep up with your value.
Don't work yourself to the bone. There really are plenty of jobs that only require 40hrs/wk and pay the same or better.
Work somewhere with a good culture.
3 and leave is the general rule of thumb till you’re at the most senior levels. Never move laterally if it can be avoided, know what the resume and experience looks like for the next level and always be working towards that.
This is extremely important. Your best raises and title changes will come from changing companies, not internally.
After a number of years with my first company (a household name), I quit and got an 80% raise. Based on how quickly my new company accepted my salary request, I'm pretty sure I could have asked for more.
Don't burn out! Ask for help and guidance when needed, and take care of your mental and physical health (get a hobby, go out with friends, go to the gym, etc.)
I've seen brilliant people burn out and end up leaving/missing out growth opportunities because of it. Now that I manage people, it is my biggest area of focus because many times the best employees are the most at risk. They keep getting praise and asked to be involved in more and more and it becomes hard to say 'no' to new projects, responsibilities, etc... Until it is to much.
When it happens everyone looses, your boss, your team, the company, and especially you.
a million times this, so many young people overwork themselves and burn out quickly
I cringe whenever a see someone has checked in code at 1am on a weekend, and these people are also working normal business hours so it’s not like they are only working at night
sadly it’s usually the same people who never take PTO either
What if my whole problem is I don’t know what I need or what kind of help I could use?
Whenever I work a job that’s too complex for me, part of the problem is I can’t clearly define what the heck is going on to even know what kind of thing would help.
It’s like my brain just start blanking out.
There is no one perfect solution unfortunately.
Meeting a therapist will definitely help to identify the root cause, and eventually will help.
Also, see my post YSK: Understanding the work burnout experience, treatment and preventions
I think the root cause is the complexity. I do a lot better in jobs where the situations might change but the rules don’t. In programming, everything is changing all the time and I can’t keep up. There’s no repetition and if you are repeating yourself you’re doing it wrong.
I need parts of the day when I’m not being creative within a formally strict environment. It takes too much processing power for my brain to do that, and it overworks me.
I know the root cause and the problem is solved because I’m working jobs that have complexity within the range I can handle.
Split the problem into manageable chunks, then attack the chunks. Apply recursion as needed.
This is part of a more senior skillset, as some times a senior will be breaking up the problem and assigning the smaller pieces to other devs.
You're not responsible for the bad decisions made by the people who have positional authority over you. Do your best. Warn them about the risks. Let yourself feel disappointed by their decisions, but don't ever accept responsibility for them. If you did your best to warn them, then you took your responsibility seriously. That's enough.
CYA in a nutshell
UPDATE: I added some clarifying points in light of getting some of this wrong. I believe the underlying point still stands.
No. I believe I understand why you think so, but just no.
At best, covering your ass means gathering evidence about how much you tried to warn the people making decisions, in order to avoid or deflect blame when things go wrong and someone starts wandering the countryside looking for people to blame. I'm not suggesting that. I'm not even suggesting saying "I told you so." when things go wrong.
Quite often, at least how I've seen it, covering your ass involves not even trying to do the right thing or, perhaps, pretending in public to do the right thing in order to have a plausible excuse when things go wrong. That's also not what I'm advising.
I'm advising not to accept responsibility for other people's bad decisions. If you genuinely did your best to influence their decision and they chose poorly anyway, don't take responsibility for that choice. The responsibly remains with the person who had the authority to decide.
For example, if the OP decides to listen to you instead of to me, that's not my responsibility. I've tried to explain my position, but the responsibility for choosing what to believe belongs with them. I'm most definitely not covering my ass; I'm recognizing that I'm not responsible for replacing OP's judgment with mine. If they ask me for more information, I have the responsibility to provide it. If they ask me to clarify my position, I have the responsibility to do that. But I am not responsible for convincing them nor for their final decision.
You have a very different idea of CYA than I (or the other poster). To me, CYA means ensuing you have evidence that tried to do the right thing and were overruled, so that you will can (justifiably) avoid repercussions when the failures you warned about come to pass.
I'm with you. Two things.
One, I assumed that the commenter was referring to the cynical kind of CYA, which I was certainly not advocating. I might well have got that wrong; only the commenter knows what was in their heart. Oops. I've tried to clarify my first comment, just in case that helps anyone else reading.
Two, I said nothing about gathering evidence to be able to produce when needed. (And I genuinely wasn't thinking about that.) I merely said that if you tried your best, then you did enough and not to feel responsible for their decisions.
In both cases, I don't think I suggested covering any ass. I certainly didn't intend to.
Thank you for clarifying and not letting me off the hook.
Exercise regularly. Maintain good posture. Stretch. It kills your body, working at a computer all day.
Above all else here, this.
If you're a developer, read the source code. People will tell you how they remember things working, or how they think they should work. The code is what it is.
I don't know if that's obvious for people entering this profession but mind that you don't read code like a book. Check how the functions you use are implemented. What's being called from where (call stack helps in the debugger). How are experience programmers managing their code etc. It's a good skill to learn how to navigate other people code and quickly find the parts that matter
Exactly! Always push for code pointers for everything people tell you about the codebase. Even if the code has a bug and isn't working as intended, it's so important to know the actual truth if what's happening.
Understand that technology cannot fix people problems. Always remember that. If you're asked to solve a people problem and you don't understand it, you will suffer. Only management can fix people problems.
Also, it may not seem like it, but software is almost entirely about people. Everything comes down to the users. You need people to use your software. You need people to want to use your software. Even if your users are other engineers, you still need users. You could build the best piece of software ever made, but it's nothing without usage.
Things like marketing, product, and design are usually equal parts of building software.
This is something that took me a long time to come to terms with.
Yup. It's definitely always about people. The people using it.
I've worked in software support, QA, and technical writing.
A LOT of developers who come in as devs from the very start of their careers know very little about how the average person might interact with the software they are creating. And what they know of, they can (sometimes) be so sneering and dismissive of that it actually impacts their design decisions. Like, "I don't care, the user is stupid, I'm doing it the RIGHT way." Even when the "stupid user" is like 90% of the population that'll use your widget.
A new (and old) dev should read past customer tickets and talk to your customer support people, as they'll have the actual real-world experience and examples with non-technical users that can give you insight into how to better create the thing that you are creating.
To make a comparison...say you were a furniture designer making chairs, and you're 6'3". Sitting in the chair yourself and proclaiming it's fine isn't enough if your users are children, women, guys shorter than you, people lighter than you, people heavier than you, and the disabled. You need to actually understand how people who navigate the world in a different way than you do interact with the thing you're making. A chair that works fine for someone who is 6'3" with two working legs might be unusable for a 11 year old who broke their foot, or a 4'11" grandmother who can no longer move heavy things around (say if the chair is solid and heavy and something a 6'3" dude could easily move).
With technology, it means average non-tech users will flow through menus differently than you, might have vision or hearing problems that you don't have that make signals from the widget difficult to decipher, and people in general who are non-techie can also be more risk-adverse when it comes to things like clicking strange buttons. And that's just the tip of the iceberg.
Interesting, mind giving an example?
Trying to use technology to control people clocking in on time or making the IT department the company computer police
Oh I see! that is a great example, thanks.
:wq
Years of imprisonment avoided
:q!
I wonder how many files I've accidentally left that in while I wasn't in vi.
For me, probably a lot.
:x
I don't like that as much because it's not as clear what it does. I remember ":wq" as "write quit".
Everyone else here who said, "Keep learning" is right on, but don't forget to work on your soft people skills along with your tech skills. Whether your long term goal is to stay in development or some other aspect of the industry, you should be comfortable talking to all sorts of people (management, sales, customers, etc...), making presentations, being social at conferences and so on. We (techies like me) tend to forget this, but it's really important.
Imagine yourself starting your own company in five years or being the senior manager of a large group. How are you going to like meeting new people every day, selling or at least explaining your product or service to them? If the answer is "not very", then start working on that now.
Ask questions, don't assume. Keep notes of meetings, and notes of your work, little bits. Always have a good rollback plan.
Ask the experts from help, and learn from them. Don't ask things you can legitimately learn really easily on your own by just doing a quick read of the code, but the bar for questions to not be stupid is pretty low. In most projects with any complexity, it's probably overall saving the company money if you ask someone who knows and can save you time, instead of wasting a ton of your time reaching the same conclusion. But next time that problem comes up, you should know how to solve it, so it saves everyone time.
If you have an opportunity to learn a new platform or technology, take it. Every environment has a different way of organizing, implementing, troubleshooting, etc. Each one you learn gives you a new way to look at a project, and teaches you something about how other people may think about projects, problems, and solutions.
People who stick with the same tech for decades are also stuck with the same approach to new projects. When the only tool you have is a hammer, every problem looks like a nail, and all that. Get more tools in your tool belt.
Depending on your specific field tough.
In front-end there are so many opinions it becomes a lot of noise so you kinda have to narrow your focus.
If you're offered a job with more money/benefits or whatever, take it. Don't give your employer the option to counter. And if you ever do let them counter out of curiosity, don't take it... Leave.
There's too many horror stories of people basically staying on after a counter-offer, only to train their replacement and end up tossed out anyways.
Loyalty doesn't mean shit in tech; any promotion you get internally at a job will be pennies compared to what you're able to get by shopping around; so do yourself a favor and run whenever the opportunity arises.
YMMV; staying can work well but you really have to know your employer, and be able to roll with the punches either way. It can be equally risky to be the new guy again. Always have an honest understanding of your replaceability.
If you're irreplaceable, you're probably doing something wrong, at least in tech.
All technical fields especially should have a high bar for documenting what you do and how you do it, requiring documentation in every form and for every aspect. In my field, IT support/sysadmin/network admin, process, procedure, common fixes, system set up, network design, etc should all be documented. The only down side to having to replace me should be the long lead time for the new person to chew through the documentation to fully understand what's going on and how it's all interconnected, and not much more.
IMO, person to person "knowledge transfer" as my current employer currently implements, is unviable, and should not be allowed to be the norm. There should never be only one person at an org that knows the job, and the current state of affairs and why the current state is what it is.
If any org does have that single worker point of failure in knowledge, then they're just one incident with a bus away from significant risk of their systems entirely collapsing. I call this the individuals "bus factor", aka, if you're hit by a bus, how fucked is everyone else? An IT person's bus factor should always be low since almost all businesses are data management companies that make money doing X; everything from users Rolodex, to the CRM, to their communications and daily working tools, are almost always entirely dependent on IT, in some way, shape, or form. Less so for companies doing non-computer controlled manufacturing, but any desk job, or white collar office would entirely collapse if their IT staff was suddenly unavailable and their IT environment was to go down. At that point, just close up shop.
I don't think I agree with you, replaceability depends on a lot of factors, really.
I'm a lead dev who works mostly in test automation and dev ops. I can assure you that no matter how much and thoroughly I document and share knowledge (I've became known in my company for that since every piece of doc has my name somewhere on it lol) I can't see anyone around there being able to fully take the reins if something happened to me.
in my case, it's a mixture of talent crisis in the industry, lack of interest/expertise in the field and my own company's culture (that doesn't value these infrastructural subjects enough). I bet other people from different areas in tech might share different reasons
but all in all, being irreplaceable is hardly an employee's fault. if a company can't manage to lose an employee (or lets people get away without documenting/sharing knowledge) it's entirely their own fault!
I absolutely get what you're saying, and it definitely depends on a lot of factors, mainly how easily replaceable you are.
I agree with the fact that it takes a combination of talent, experience/expertise in the field, and the company itself (mainly it's culture) that can dictate a lot of that. However, things like previous experience, and talent are not exactly things you can pass on to a new technician via any form of documentation without chronicling your life story with every instance of needing to do anything remotely technical which may lean into the problem-solving skills and thought process you uniquely have, and even then, on-boarding that experience would be a monumental challenge. Simply put, that's not practical. Even that, doesn't account for any ability to pass on talent, which isn't quantifiable in any meaningful way.
The main argument I have is that the knowledge of the organization's systems, how they interconnect, why those interconnections matter, how they work, etc. should not be up for question or debate; and it should only be a matter of finding someone with relevant past experience in similar systems, with sufficient talent, who meshes adequately with the company culture, to be found, in order to replace someone.
Unfortunately, finding someone with sufficient talent is often the most difficult part, and since it's difficult to assess talent in an interview or even a set of interviews, it's usually impossible to know if someone is going to "fit the bill" so-to-speak, until they've been thrown into the fire.... This is the reason for the probationary period of most workers, both for the benefit of the worker, if they're not meshing with the company, and for the company, if the worker isn't capable of doing the job. Unfortunately, often, especially with I.T. work, it's difficult to know whether someone is going to work out long-term after a few months, especially when the amount of knowledge someone needs to have to actually do most tech jobs is so monumental that it's unlikely that the new hire is going to have any significant depth of knowledge in the technical systems within a few months of being hired.
All of this sets aside the factor that every individual is unique and makes unique choices and contributions to the whole, so even "replacing" a very replaceable individual position, isn't a 1:1 comparison, the new worker may be worse, or indeed, even better, than the previous one, but rarely, if ever, would perform EXACTLY the same in every circumstance.
My core argument is that the information about the system (which needs to be supplemented by talent and experience), should never be lost if an employee decides to walk (either by finding a new job, walking in front of a bus, or off a short pier). If that information is lost, it's a significant managerial oversight which allowed that to happen.
yep, agreed will all of that
in any case, I never been somewhere where this is properly done to the letter (from an individual's or managerial's perspective). not that I REALLY care tbf, I just do my part to the best of my knowledge and fly away hehe
I can appreciate that. I just think we were arguing the same points overall; and as demonstrated, there's a lot not nuance, not only to the idea of what "replace" means, whether it's simply having someone fill the role, or having someone do the same job at approximately the same efficiency and level of output, to what other factors may go into the job that cannot be transferred to newcomers by way of speech, text, or video.
There's certainly a lot to the discussion, as is the way with many things, but the amount you can help the next person by why of documentation, should always, ALWAYS be something that's baked into the job.
Hilariously, I advocated for better documentation at my employer, they gave me every excuse under the sun about it. I was only really asking "which documentation system are we moving forward with?" And got no clear answer. Work has ~4 different sets of documentation, all of which are in varying levels of being obsolete, irrelevant, or incomplete. I wanted to fix it and nobody could decide what to do, so I did nothing.
About two months ago, I hit burnout, and now I'm on medical leave. So essentially, I had a bunch of information that nobody else had, and I was incapable of putting it into documentation, either due to the uncertainty of where to put it, or the whole zero hours a week that work gave me to document things.... And then I was metaphorically hit by a bus.
Sucks to be them.
yeah. I have the feeling that this story is way too common. which is very telling of how much the system isn't driven towards innovation as many claim. we brag a lot about human ability to pass down knowledge via written language and turns out that most information passed down on some of the highest tech industries is done verbally or not at all! lol
Ultimately tech is a tool to help automate and solve people’s problems. You want to get close to the people your solving problems for so you can get feedback and figure out how to do your job. Your organization may not do this for you. I spend a lot of time on forums listening to my users, and do a lot of extra testing to make sure I’m solving there problems and not making new ones.
I can think of three big pieces of advice:
Are you sure? I think the golden age of the magic tech jobs is nearing its end. If you want to join the tech industry because it's an easy ticket for a successful life then you might wanna rethink that. If you want to join the tech industry because engineering is pure magic and you want to be a part of that, then by all means, you do you. Just be ready for it to be a bumpy road if you aren't able to adapt to whatever AI does to the industry over the lifetime of your career.
Find companies who will treat you right, and where people are real and do real shit. When I was first starting out, a project I was working on was behind. I stayed over the weekend, even though people told me not to. I finished, I was proud of myself. Then I came in on Monday and everyone else's stuff was behind anyway, so we missed our deadline regardless, and in the end it didn't matter. Right around that time was when I decided, more or less, to hell with this. At the company I eventually jumped ship to, my boss would regularly push back on clients who wanted us to work weekends, come by and encourage people to live a normal life instead of just a working-to-death life. Basically, he looked out for people. So I stayed there for quite a while. Basically, after that experience, if the boss wasn't looking out for me or the tech was shoddy, I bailed instantly. You gotta have a good human life and take pride in what you do.
Own up to your fuck-ups. You'll make some. I've destroyed important hardware, made massive architecture mistakes on client work which the clients then identified and talked to us about, deleted the partition table on an important public-facing server, you name it. When I did something like this, I would be 100% upfront about what happened. In good working environments, people would recognize and give respect for that, because nobody's perfect. In bad working environments, being upfront about mistakes would somehow be a bad thing (see point #2). The answer is not to become sneaky. The answer is to leave and go somewhere where people respect honesty. Those places do exist.
That third one can be tough, but I think it’s super important, and, not just in tech.
An easy way to confirm your first point: would you still want to do it if you were paid significantly less? If so, then yeah, you're in the right place.
Point 1 is pure speculation. You could say the same about any profession. Absolutely not something woth considering when looking for career opportunities. You can always pivot with your career and knowing how to code is a plus because that makes you understand tech better
Remember tech-companies exist to make money, not to "do good." Whatever problem they are supposedly working on, they are only doing it because someone thinks they can eventually turn it into a revenue stream. Don't drink the kool-aid, be a mercenary and get as much out of it that you can until you can leave for good. Dont' be the like the smuck's that are still working at twitter.
Yup, and this applies to any company. If you don't own the business, you are a line item, not "family". Always be ready to jump ship for a better opportunity, because they will do the same.
Don't be evil
Wasn’t that google’s slogan once
Yes but being evil pays better.
No more than 2 years in a same company and always be interview ready. Keep regular contact with recruiters. There’s always a better opportunity.
This is exactly what my friend did. He earns double my salary even though I work in one of those big companies and do more than just development.
Don't burn yourself out, document everything.
When interviewing, if a company gives you the "We work hard and we play hard" line, run. It actually means tons of unpaid overtime in exchange for some snacks and a broken ping-pong table.
Never stop learning. Most important advice IMO.
Tech is a field that is constantly evolving, whether you're a developer or IT service desk, the tools you use today will probably be very different 5 or 10 years from now. Never get stuck in a rut, it'll burn you later in life. Remain curious and keep learning the new things coming out.
^^^
Always be hungry to learn new things. Don’t get too attached to any system or process.
The best engineers are the ones willing to adopt and drive new tech.
Set boundaries.
At my first professional job, there was one guy who always came in at exactly on time and never stayed late. I always thought it was weird, I'd typically stay at least long enough to finish whatever thought I was working on, and sometimes later just because I had nothing important to get to. Eventually I became one of the guys to go to when you needed someone to stay late. I didn't mind, in fact I like being helpful. Looking back, I realized that I gave the company a lot of free work and didn't get anything for it. It seems obvious but important to realize from day one, you are setting expectations. A "good" manager will figure out pretty quickly which employees they can exploit and how.
What area of the tech industry are you starting in? It would help to know so we could tailor the advice to you.
you will end up bringing down production or make a however many tens of thousands of dollar mistake. Don't worry about it too much when it happens. That sort of thing doesn't usually get you fired the first time.
Be transparent about your mistakes and learn from them - better yet, help make sure others won't make the same mistake.
Read the damn code
So many problems can be solved by just reading the code. A corollary to this: make sure the code you write is readable.
Another correlary: learn lots of languages, even if you’ll never use them. I never want to fall into a codebase that I’ve never even learned the paradigms. One procedural, one functional, one OOP, one interpreted, one compiled, one byte code compiled, one or two command line scripts, regex, all the structured data text languages: XML, CSV, JSON, YAML, TOML, … A JavaScript framework. HTML. A relational database, a non relational db. REST.
Should be enough to get started lol. But you learn something from each, about code architecture at least.
Always learn the languages preferred directory and repo layout structure, never invent your own.
Be hard-working but loyalty will take you almost no where. Every 2 years you should start looking for a new job with better pay and less hats. If you are a year in and hate it just switch to somewhere new. I got 2% raises at jobs year to year but switching jobs for me got 20% - 40% more.
Make things just complex enough that others don’t want to learn it but not so complex anyone can say it is too complex.
Also pick up tasks others don’t want to and make yourself hard to get rid of.
Then quit and get hired back as a consultant/contractor and work your own hours and how much you want to.
It can depend on the area you're going into, but things like continuous learning of new skills, as well as keeping up-to-date with the latest happenings in that field, are always good ones to do.
All other comments in the post are gold.
Always stay relevant with skills and knowledge relevant to the market - one day you work for papa Google and everything is great, another day you'll get fired without you seeing it coming - job is not a family.
It's fun and games to master a skill/technology, but if there are no jobs for that, that is a red flag.
Generally it's important to keep the hobby-job balance, and to understand that sometimes your hobby specifically won't be your job, and that is OK because most of the people are like that.
I’m looking to change careers into tech at 43. I’ve been a teacher my whole life but education is…just not a good job anymore. I’m very interested in data science and would love to end up working on climate modeling but I’m practical and understand that I should take what I can get. Anyone have some career wisdom they’d be willing to share?
Afaik (I'm an environmental geologist) Climate Modeling isn't really tech, or the tech industry, it's more academia. Most climate modelers I know of are working off grants in university labs. That may/may not help you get into it, but if you're seeking something that is a deviation from teaching/education, academia isn't much better for all the same reasons really.
Do you have a background in climate science or environmental science? Or modelling for that matter?
I don’t have a background in it. I’ve been a public school music teacher most of my career, but I’m also a lifelong nerd and the draw of making a difference in climate change using math has been just too attractive these last few years. In January I start online classes in statistics, Python, and data management/analysis from a local university. I don’t want to end up in a university lab though. I understand that breaking in in a new career will mean taking what I can get until I’m better experienced.
What area of the country are you in?
Water conservation and environmental protection are probably your best available avenues into a climate science career of any sort. I've worked in environmental since 2012 when I got my master's. I specialize in hydrogeology, but there are lots of fields. The problem you will run into is they are gated by credential barriers at a certain point - specifically PE/PG requirements. If you have the math portion you are probably well capable of passing the PE exam, you just need the experience and recs, so you may want to tailor your class load to put you on that path. Engineer's also generally have higher pay brackets so there's that little carrot as well.
Most environmental based companies, regardless of their area of focus, have modelers and need engineers of various backgrounds. You typically don't get hired into modeling, but can sort of steer yourself that way once you're established. I'd recommend you avoid environmental consulting - it does not sound like the work environment you're looking for, and most clients end up being polluters. Water Purveyors could be a really interesting target to aim yourself at. They do SO MUCH more than water supply, and they are constantly looking into all kinds of interesting projects. When your job is to supply an ever increasing population with an ever dwindling supply of a crucial resource, creativity is very much necessitated.
"what area of the country" 🙄🙄 You know there's more than one country?
I'm am absolutely positive that OP only lives in one country, not two or three. Do you think he lives in more than one? Or are you just surfing around trying to be pedantic?
Water Purveyor wasn’t even on my radar - thanks so much for that insight! I will definitely look into it. I did worry there would be some certification barriers that might be difficult to achieve either because of time or expense. I’m on the east coast, though, so not perhaps in an area where water conservation is front of mind for many.
As far as barriers, better to know where they are and how big they are now so you know exactly how high the metaphorical ladder you need has to be. All municipalities have water purveyors of some sort, but you're right in that they'll likely be less focused on conservation. They won't however be less focused on protection and they may still have beneficial use projects. Also that's not inherently bad news for you - it means a likely lower barrier to entry.
Anyways best of luck.
I did the same at about 43. Had some tech support background and could talk the talk, so that helped.
Got no solid advice, except to so it doable. And don't let anyone tell you coding is a "young man's game". That held me back for years. We got coders of all ages, beginners to near retirement.
That’s so good to hear!
Be patient. It takes time to "get going".
If you know how to program, you're in a good spot. If you don't know how to program, start with fundamentals.
SICP is good. It's Lisp. You'll probably never write a line of Lisp professionally, but it will help shape how you reason about solving problems.
Develop some solid fundamentals.
This sounds like a conversation for you and your manager. I've had a few with my team that have resulted in different solutions for different people.
With one we established a monthly 1h call for her to explain where she is stuck, what she has tried, and we brainstorm how to get through it. This is separate from our usual weekly check-ins and focuses on issues related specifically to complexity and ambiguity.
With another, he created a list of what she thinks needs to happen and puts together ideas on how to get through it. I review it and then give him feedback. He liked this as over time he built confidence on his ideas as my feedback more often than not was "exactly what I would try, go for it".
Finally, sometimes is about reducing the work load on that team member until they get a good foothold and slowly start adding more.
Shot answer, no one solution or easy path, but communication with your manager and hopefully a good manager is your besy bet.
Leave. It's all going to hell.
Here is what I did. I bought an IBM ThinkServer and put as much ram as I could in it (32GB; keep in mind this was 2015). Then I loaded it up Windows Server by itself and played with the Windows and its features. Then I loaded Hyper-V to play with virtualization and created my first domain environment, learning DNS, DHCP, GPOs, an Exchange Server, and VPNs. I ended up throwing a 4-port NIC in there and set up pfsense on a VM to act as my firewall router so I could learn VLANs, traffic shaping, and security. Then I put ESXi on there and learned vSphere and vCenter. You can sign up for an NFR key from Veeam and play with backing up a virtual infrastructure.
There is so much you can do. I started out on Helpdesk in 2015 and now I am a Senior System Engineer that works with the VMware platform all day. If you invest in yourself, it will directly invest in your future and how quickly the promotions happen, and the amount that the responsibilities increase. Feel free to reach out and DM me if you have any other questions that I could help with. Good luck to you!
Don't get overwhelmed if the task seems too difficult or complex. Take time to write it out on paper, break it down in smaller parts and tackle them in turn.
But... Also be honest with yourself if you're struggling, there's no shame in admitting that you need the help of someone more experienced.
Specialise in an area AI won't be able to do in five years time.
Do some study in your own time.
If you aren't sure what to do and like servers etc, just do the Microsoft courses. Having these on your resume gets you ahead of people that don't have them at all.
One of the best things a Senior Eng taught me was to understand and ask questions about every single line of code in a file you’re touching.
It’s daunting, and time consuming but the rewards are vast and eventually it will be much quicker. Of course it’s easier to follow patterns and make quick changes, but it’s more valuable to fully understand what you’re doing instead of suggesting changes that should work.
Relevant thread: https://programming.dev/post/572051