Learn how to share your ideas and opinions in a concise, engaging way. Learn to advocate for (or against) something in a way that will have people engaged (first point: never be combative, people will mostly dismiss you as immature or emotionally compromised).
Yeah it doesn't sound like a "tech skill" but it absolutely is and I think too many "tech" people severely undervalue it, preferring instead pure "lone wolf" kind of skills that don't require the squishy, dirty aspects of dealing with other humans (speaking from personal experience here).
You can accomplish a lot on your own with the right talent and skills. But you can always accomplish more if you can engage more people.
Maintain a blog of interesting things you've learned, hiring managers will value the demonstrated writing skills.
Anyone have any tips for communicating more concisely?
Some things that have helped me:
- care less that people listen to you (see also: The Subtle Art Of Not Giving A Fuck). If they didn't get you the first time, their loss.
- Keep in mind that repeating points doesn't actually help most listeners, as you're just overloading them with information. (for advanced writers only: there's an art to repeating points for reader memorization)
- Remove a random sentence. Does your point still make sense? Then the sentence wasn't crucial. Does it not make sense anymore? Then can you add a qualifier or clause to another sentence to make sense again? Counter to this: make your sentences as short as possible. Be liberal in splitting your sentences. Iterate these two steps.
- Remove adjectives and adverbs
- (always valid) review what you wrote 5, 10 minutes, and/or a day later. It's fascinating how a bit of distance makes you realize the flaws in your past writing. When you're writing, you still have your idea clear in your head, and your understanding of what you wrote is informed by the live idea. After you step away, you're left with just what you wrote, and it must make sense on its own.
Addendum: are you feeling that people aren't listening to you because they're not acknowledging you? Many people are bad at acknowledging what they hear, so learn to do without. Conversely, learn to acknowledge what someone else is saying ;)
I used to belive this, but after some horizon-broadening reading/listening that went far outside of my usual technical inclination, I noticed that there are some that are deeply convinced that repetition is the key to effective communication with normal people (by which I mean most non-technically inclined ones). Just listen to managerial podcasts (for example www.manager-tools.com) or read any book on marketing or NPL programming. Most of it is probably bullshit but there is one theme that persists through all of this (repeats, if You will :)).
I started to wonder if my drive to not repeat myself is somehow deeply connected to my technical life (I spent most of my life programming, DRY-ing my code, and reading complex technical books that cannot afford repetition because the material is too dense).
And maybe this is not how the real world works - maybe the other 95% of it needs everything repeated till their ears and eyas bleeds - otherwise they will just ride through it like they ride through their facebook wall.
And unstructured, dispersed, realtime communication is not going to cut it.
The skill to develop is time-boxing and scheduling communication, as well as avoiding communication silos.
You want to be an engineer at a small startup:
* Typescript and be familiar with common libraries and frameworks. I believe TS is going to become more common everywhere, frontend, backend, DevOps, etc.
* Learn python if you don't already know it
* Learn some kind of data science stack you can use to analyze small data sets (under 100GB). Pandas+numpy+scipy, Julia, whatever. Just be good at answering data questions and building small models.
Big company:
* Writing and communication. Practice writing about projects you've worked on and write down the projects you want to build with enough details that a junior engineer could build it.
* Be aware of how much companies are paying and be willing to leave for better compensation, work-life balance, or responsibilities. Practice interviewing.
* Read all the major postmortems from incidents at a big tech company and try to find patterns related to your area or part of the stack.
1) Data infrastructure. This is the inner loop of a lot of tech companies. Speed it up, reduce the cycle time, reduce the AWS spend and you’re a god.
2) Data science. Provide better insights into a domain or its customers, or as above, provide a better platform for others to experiment and discover the same, and again, be worshipped.
3) Customer success. Discover that your business is in a local maxima but could shift to provider vastly more value for customers, ditto.
4) Hiring. Forget how great you are, if you can hire great(er) people then you are an almost exponential factor in your company’s success.
1) Continuing to stoke the flames of curiosity and discipline within yourself so that you genuinely love to learn and get slightly better every day without fear of perpetual burnout.
2) Confidence to ask questions in group settings so that you can quickly get to a collective understanding of the problem space and challenges at play.
3) Communication. Litmus test is being able to present what you're doing in an understandable and approachable manner that can get the right people engaged.
And to answer the spirit of your question more directly, some technologies that my team have found to be super valuable:
A) Hasura (GraphQL/ORM layer to interface with Postgres)
B) Pulumi (TypeScript IaaC)
C) React (nothing super new here, it just continues to be incredibly valuable to us)
D) NestJS (TypeScript-friendly framework that is like Angular for the backend)
Also, Pulumi feels like a distant second to Terraform.
Also-also, writing Terraform code for SRE/infrastructure tasks mostly feels like unrewarding grunt work.
I'm thinking that having experience with a capability based operating system such as Fuchsia or Genode as a daily driver will be quite valuable, as you'll be ahead of the adoption curve. I hope to have this happen myself next year.
If you haven't already, I recommend doing the Advent of Code puzzles, all of them, in whatever language you are comfortable in. Redo them in whatever language you want to learn, ad infinitum. I personally haven't gotten through all them in Pascal yet. I did last year in real time, and except for day 19, and current in 2021.
I suggest you learn a little bit of practical machining, that done in machine shops. The process of using machine tools to make things, otherwise known as subtractive manufacturing. I'd also suggest you learn additive manufacturing as well. It is good to understand how the atoms around you came to be configured as they are.
There you go, 3 things to learn for 2022.
The tool manufacturer Sandvik also has a decent free online set of courses that I found helpful.[0] I have also heard people mention the Titans of CNC online training courses,[1] although I have not checked them out personally.
Finally, "Machinery's Handbook" is also a venerable resource that deserves mention, but more a desk reference than something to read through as a learner. They come out with new editions regularly, but older ones are still very useful (and have better quality bindings).
Overall I would recommend seeking out resources that are addressing a professional audience, rather than a hobbyist one. Hobby-level discourse and instruction about machining varies widely in quality.
[0] https://www.sandvik.coromant.com/en-us/services/education/pa...
I have questions about how much it would cost to get started in the way of tools, but I'd imagine the resources above will cover that, so I'll RTFM. I'm hoping it won't require my finding some old-school lathe from the 1950s...
Prefect: https://www.prefect.io
Dagster: https://dagster.io
Learn stuff that will enable you to be better at what you are doing. This might be
* tools, techniques for development
* techniques for learning
* understanding of the underlying systems
* understanding of the processes involved
or you can choose any from https://www.thoughtworks.com/radar
I'm guessing from your comment that you don't work on anything related to AI.
In 1992
I thought declarative programming was the way of the future. I was wrong. It is useful in a small set of cases but generally speaking procedural programming (still) rules the roost.
It seems everybody is learning lessons learnt in the 1950s over and over again.
Prolog is hard to write. When you modify it, you have to understand the logical world state.
Outside of academia, there's no use for prolog.
Prolog certainly has been used in industry; https://en.wikipedia.org/wiki/Prolog#Use_in_industry has some useful discussion, and https://news.ycombinator.com/item?id=29539384 talks about its use in network software.
With regard to this, though:
> When you modify it, you have to understand the logical world state.
That's true of any non-trivial program someone may write and/or modify. Changing without understanding is just going to get your garbage (perhaps functional garbage, but still garbage).
"Tech skills" is an enormously broad category on its own. You provide no context, so there's no way to narrow it down.
What do you want to do in your career? Answer that question first.
Include removing "all the things" from your vernacular. It's not 2010.
Low risk: React
Medium risk: Android Jetpack or Flutter
High risk: OpenAI Codex
Can't go wrong with any of those.
Otherwise yeah, Svelte and Typescript are pretty dope.
Such broad generalization can can be said about any technology.
You probably meant things like Kubernetes right? Well, that's no longer Docker. Kubernetes even work with Podman so it's not a Docker-only thing.
Stick with Docker and you'll be alright as far as technology to learn for 2022.
VR
Blockchain
Smart contracts
k8s
k3s
k9s
No-code
Web Assembly
Quantum Computing
GPT-3