What is your process for learning new technologies and staying "in the loop" of knowing what are the new techs that can be useful to you
Posted by xSypRo@reddit | ExperiencedDevs | View on Reddit | 21 comments
Hi,
I am currently in the process of choosing the tech stack for new project.
Coming to decision of building an app or website I realize I am leaning toward a website only because that's the tech I know.
Starting to investigate the topic of app building I see multiple options but finding info about them is challenging.
I don't want to ask about app building here, I want to ask about the process of learning new tech for you, how you approach it. You want to do X, how you investigate what are the best tools for it currently, and then how you choose which one to use. And then how you approach learning it.
And then also how do you stay on the loop of that tech stack, to hear about new tech that can be useful to you?
Educational_Pea_4817@reddit
as a team we dictate what technologies we are using for whatever project or projects and then we take the time to brush up and learn.
this can be self study(during work hours) or training, certification, etc.
what are the demands and/or requirements of the application in question?
does current tech stack meet those demands?
if there is a deficiency in current tech stack(or starting from scratch) what possible alternatives/additions does your company willing to support?
what technologies is your team most familiar with?
what technologies does your team WANT to use and support?
pydry@reddit
Keep my ears open.
Try to find out what other people have said about the new tech, with a bias against hype and marketing and a bias towards rants ("I used this and it was a piece of shit..")
Spike the new tech - with a bias towards trying to find out all of the dirty corners asap.
OtaK_@reddit
It depends.
If it needs to hit production at some point, use proven stuff. You might go for something unfamiliar for you, it's going to be harder and longer but you'll gain value as an engineer. If it needs to go fast, use something you know.
If it's just a whatever project to learn stuff, then use whatever. If it sticks, it sticks.
besseddrest@reddit
My process: Keep the fundamental knowledge sharp. Learn the new tools when you have to, but make an effort to understand what purpose it serves. Give it a try if you want to.
The nice thing is that I never feel compelled to learn something that is the new hot trend. E.g. I don't feel like I have to know Tailwind to prove to a potential employer that I'm proficient w CSS. I feel I know enough to hold a convo about TW if asked in an interview, and enough that if it were in a technical question that I could make sense of what is going on.
GoTheFuckToBed@reddit
I use it and write down (or record) my findings
originalchronoguy@reddit
I am fortunate to get thrown into new, unknown territories.
The last 10 years of my career has been a series of RDD (resume driven development) and this was never the intent. I may appear like it but it was never the intent. Things fall into your lap and problems/pain points need to be resolved.
So for, evaluating new tech means how quickly can I spin something up -- locally. In Kubernetes. Where I can stress test it, pilot. Then push to a staging environment where more people hit on it hard --- DDOS, stress, load,etc, you name it.
Sticking to what is familar can be very risky. We did that on our last project. They picked the "safe known" solution. It, was by all means "safe." I wont get into specific but it is a database with vector extensions.
Out of the bat, everyone knew how to use it. But it always struggled under "light load test." Even in prod, it was brittle. No amount of sharding, replication, pooling solved the problem.
Then, here is this new shiny thing. A lot of people are adopting it. For a reason. I won'y go into the name so I don't out myself. But, I went ands tried it.
Deployed it. Loaded it up to 20TB of data. Stressed tested it. It perform well. It performed as all the "hypers" in the tech blogs are claiming it would do. So I tried it out.
Now it is just trying to convince the rest of the team. They live of facts. Proof, results.
So, challenge to them was "Hit this as hard as you can. 1,000 10,000, 30,000 records per second"
Check the DR (Disaster Recovery) and MTTR (means time to repair). If this takes 40 seconds to restore versus 2-hours, than I challenge them to show how the status quo is better. There is a reason why some new shiny object is getting fast adoption. It is getting adopted because it is simply better.
Same argument in 2014. Who wants to use k8 when we have vSphere? It only takes a few trials, evaluation and real world fact based scenarios to sell that tech.
That is how we test and evaluate new products.
mnemonikerific@reddit
Re: staying in the loop: I think the best way to describe my approach is to be the Jupiter or Saturn and cast a wide net of having info dropped on me via notifications from Twitter and Reddit - which I can scroll past when community and bookmark stuff to catch up later, or in a future life.
re: learning something new: usually theres a consistent pattern, and the biggest “wall” I ran into was going from AngJS to Angular and then to React, and maintaining them at the same time (absorbed / inherited codebases). With react I had to unlearn many things and re learn them through many hours of poring over docs, sample code, reimplementing starter projects, stack overflow, online courses and YouTube. with YouTube I had to set a very narrow filter to make sure I only got the latest information.
ArchitectAces@reddit
The people that make that tech also write on how to use the tech. I know this crazy, but I read it.
Have you tried reading technical documentation?
Idea-Aggressive@reddit
Why the downvotes? Starting to get ridiculous
soMbadGG@reddit
Figure out comparable tools/tech and audit what they're using.
Antique-Stand-4920@reddit
After a project has been set up, I often keep up with new tech by having to research solutions for new problems.
bland3rs@reddit
I don’t like using any new tech for a fundamental part of the project for a new project.
I build small side utility or prototype apps at work here and there when I want to try a new tech.
Some things get popular but you find it sucks when you try it and if you already built your whole application using jt, you’re toast.
Vector-Zero@reddit
I'm mostly a C developer, so nothing has changed.
nikki969696@reddit
There's nothing wrong with going with what you know, unless what you know is too outdated to want to use for new apps.
I tend to follow blogs and social media for my area so I learn about new stuff there. This is work and I do it on work time mostly, during meetings, lunch, etc. If something looks interesting or like it might apply for our apps, I file it away in my back pocket (okay, a browser bookmark) for later.
Having chosen a couple duds, now one of the first things I do is check into the ecosystem. Plugins, add-ons, whatever applies. Are there packages/libraries to do stuff and do they work well for our use case? Is there a community to ask help from? Is documentation decent? Find your biggest pain points and make sure whatever you evaluate / POC has those use cases tried out. I didn't do this the first couple times and boy did I pay for that.
Personally, I work on enterprise (web) software, so I'll never go with bleeding edge again. That has bitten me in the behind twice now when the stuff didn't take off and we ended up having to swap to a different stack anyway.
minimal-salt@reddit
i usually start by checking what other devs are using through blogs, newsletters, and community forums, then narrow down options with small proof-of-concepts before committing. to stay in the loop, i follow a mix of twitter devs, newsletters, and release notes of the tools i use
zoqfotpik@reddit
Get assigned to a project that "leadership" has decided needs to be on a new tech stack.
Ask everyone involved if they know anything about the tech stack.
Discover that nobody knows or has any idea.
Read all the documentation and books I can find as fast as possible while swearing.
Do my own part of the project.
Teach everyone else how to use it.
Eventually figure out the pros and cons of the tech stack.
Decide that it's a pile of crap and never use it again.
dacydergoth@reddit
I used RSS feeds to scope out the "chatter" around new tech and when it seems like it is gaining traction I do some prototyping. Current doing a rust+leptos project with some limited AI assist and it's going great.
gmatebulshitbox@reddit
My process is called Don't resist. Everybody around brings something new. Don't resist getting new technologies from people around. Watch and observe. If it's good it's good.
interrupt_hdlr@reddit
First look at the tech and get a sense of what's like (gut feeling kicks in)
Check what others that have used it extensively think about it
Try a PoC myself to see if it works
Start thinking about Day 2 operations and how it'd look like
Trash it or adopt it in a bigger project
EliSka93@reddit
It's hard to proactively do that.
Whenever I start building something new, I research possible technologies and choose the ones that best match my requirements - if I find something new I believe to be a significant improvement over technologies I know, I will learn that.
I however don't go out and try to find and learn technologies just on the chance I might use them.
TheStatusPoe@reddit
There's a lot of value in choosing a tech stack that you already know. Also, all of my learning is done at work on the clock. I usually reserve those 15-30 minutes in between meetings as time to read up on blogs, or books, or various other sources.
At work currently I'm modernizing our deployment in our CI/CD pipeline. For configuration management, the popular options I found were ansible, puppet, and chef. I ended up going with ansible in part because I'd worked briefly with a terraform/ansible stack before and it helped jump start the work.
When choosing new tech however, documentation and community support are the main deciding factors. I'm going to have issues going with something I don't know, so the more help I can get the better.