It depends on what you already know. Picking up new skills that are similar to what you already know isn't a big value add. But picking something up that is completely alien to your current skills not only adds a new skill, but makes it easier to pick up anything similar.
In 2032 it will be possible to correctly answer that question, with 9 years of hindsight to assist. ;-)
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.
I've wanted to dip my toe into the machining world. I have basic tools, mainly for routine home maintenance. Is there a book, website or course you'd recommend to get started?
I'm not who you are replying to, but I would recommend the textbook "Machining Fundamentals" by Walker and Dixon. It's the best 101-level introduction to the topic that I have found.
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.
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...
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.
It's not a horrible answer, though it wouldn't make my top 3 list. Learning different models of programming is almost always worthwhile, though how much time you put in will depend on your objectives. Languages and systems in the declarative/logical/relational vein like Prolog, minikanren, and others are worth examining at least once. If you grok them, it can be very handy with prototyping, even if it doesn't make it into production. And if you really grok them, you can Greenspun a Prolog into your system more effectively when it turns out its model is actually appropriate to a portion of the system.
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).
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.
The concise part is one I've been working on. I find that I've said everything I need to and I keep presenting a feature by just repeating what I've already said in a different way. Same with text via email and Slack, but I've been pretty good at catching myself recently.
Anyone have any tips for communicating more concisely?
I've been working on reducing the habit of repetition. I think it comes from (feeling like) people not listening to you.
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've been working on reducing the habit of repetition. I think it comes from (feeling like) people not listening to you.
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.
The biggest gains I'd recommend for just about everybody in a tech field:
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)
Depends if you mean “providing the most value” or “most likely to keep providing value”. The latter is kinda boring. The former is more interesting but depends on what you’re interested in:
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.
I'm a former startup founder and staff engineer at a big tech company. It depends a lot on where you want to be. Here's my take.
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.
Prefect Orion, already love Prefect and I think the applications for a DAG workflow engine are much wider than anyone even imagines
Pytorch, finally picked up a Jetson.
Back to VHDL, Sparkfun just released a new tutorial with the old Lattice board.
VXLans.
The new C++ coroutines.
68 comments
[ 2.7 ms ] story [ 157 ms ] threadI'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...
[1] https://academy.titansofcnc.com/
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...
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).
Prefect: https://www.prefect.io
Dagster: https://dagster.io
- https://clickhouse.com/
- https://kubernetes.io/
or you can choose any from https://www.thoughtworks.com/radar
"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.
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.
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.
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.
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.