Technologies change everyday.
Web is fast changing.
From static HTML, Dynamic websites and to WebAssemblies.
And You see a bunch of new JavaScript libraries released everday.
It's hard to keep up and skillsets change every few years.
But I see developers using vi/emacs/make/gcc skills for decades.
🤔What are the evergreen skills you can invest in (or learning now)❓
** Update on 12/14/2018 **
Check out this great post by Alex Fawkes, in which he discusses the topic more in depth.
Top comments (61)
Algorithm Complexity en.wikipedia.org/wiki/Big_O_notation
The 5 Whys en.wikipedia.org/wiki/5_Whys
Technical Writing - how to put together an email, a report with headings/subheadings/TOC/Index, commit messages etc.
Public speaking and the mastery of composing a slide deck
Communicating technical ideas with a non-technical audience
I've been doing professional software post college for almost 18 years, and did co-op jobs in highschool and college before that.
All of the above has served me more than anything else, with two additions:
-- Empathy for the actual people who are paying for the product you're working on as well as the people who will use it (and of course the people who came before you)
-- Knowing how to learn/reverse engineer/listen to people (which of course also leads to the 5 Whys)
Outside of that, the two technology things that haven't changed for me:
-- Basic relational database skills
-- Basic high level networking (as it computer networks, since I've already covered people skills). The how things get from point A to point B hasn't changed a lot.
Interestingly both of those technology items look to be ripe for change. relational databases are beginning to lose share to NoSQL databases like Mongo, and SDN is causing some massive upheaval in the networking world, at least inside the datacenter.
For the networking piece, I don't entirely disagree, and should have clarified that even with SDN (software defined networking for those reading that don't know the acronym -- also look at "infrastructure as a service") and all things cloud, the really basic stuff hasn't changed in that you still have ports, HTTP/HTTPS, etc. Now, some of those things are way easier and faster to work with, and there's more opportunity to move quickly knowing the what and not the how (I know that you can spin up instances on AWS, but not how Amazon is actually running their datacenter), but for a dev to talk to a devops or full hardware person in their terms is a legit skill. Even with stuff like containers and serverless, knowing the basics can still save a ton of time.
As for databases, I'd say that swings back and forth. Relational isn't going to ever completely go away, because it's the best solution to a specific block of problems. The implementations are improving in response to popularity of other options, and ORMs help developers dramatically in not having to deal directly with a database, but knowing the basics of how they work can make a huge difference in otherwise simple code. If anything, you've reminded me that I should have expanded my statement to include data storage in general and which does what/how to interact. Sometimes a graph database like Neo4j is a way better choice than something like Mongo. Regardless, any variation I've seen still has some concepts of set mathematics to deal with your data.
Also, some of my statements come from the fact that I work with a lot of legacy modernization, where sometimes you're moving from a 10 years ago framework to a 4 years ago framework because you can't convince the customer to get into the 2018 framework just yet (or they started 2-4 years ago and can't upgrade again for a while). That, and even newer things in smaller orgs often involve convincing a CIO/CTO who stopped being technical a few years ago that the "proven" method they're used to is outdated -- or worse, they're on board but years of various security policies keep things locked in.
So yeah, agree with you on some level on both counts, but also would note that the shelf life on technology is way longer than tech people often give it credit for being. A year ago I was working on a project moving an organization off their mainframe to a 2014ish era web app (because that's when the project started). My last job involved working with a vendor that sold us something written in Delphi, and it was created way later than the 90s. Disruption is happening, but outside of certain sectors, it takes a very long time to spread, so knowing the slowly changing basics is still helpful.
Hi @mikerg , Do you recommend any link/course/video/guide etc for the "Public speaking and the mastery of composing a slide deck" thing? It would be very helpful if you could.:)
Thank you, Mike.
Those are valuable skill sets that we can apply for our lives, as well.
Thank you for your sharing.
Based on my own experience these have been some evergreen skills...
Thanks, Douglas.
As you pointed out soft skills seem relevant in IT field, as well.
Would you have any recommendations on how to develop it?
Yes soft skills are very important these days; all companies I have interviewed at quiz me about being able to interact with clients, team mates, and others in the company.
I was very fortunate early in my career to go on a "Train the Trainer" course where we were taught about how people learn - visually, by listening, and by doing/hands-on (VAK as described here nwlink.com/~donclark/hrd/styles/va...), good techniques to structure courses for example to have a list of what the students will learn at the beginning of the course, teach them those things, and then show the same list at the end to remind students of what they have learned. Also giving them a hand-out or link to a repo with some information they can read after the course, which utilises the principles of repetition.
Train the Trainer was a fantastic course and I would certainly recommend something like that for anyone interested in conducting training with clients or the general public. There are probably some good online courses these days.
As for talking with people, the main thing is practise. So as a dev asking to be included in meetings with clients rather than just a project manager, BA, and/or designer meeting with them.
I have not been through the programme myself, but have heard first hand from a number of people I know that Toastmasters really helped develop their speaking skills and confidence, not only talking to groups, but in one on one situations. A friend just last week told me how much it had helped him in interviews for jobs.
Thanks.
Wow 🤩
Thank you for sharing.
How I understood was that the soft skill is an art learned through practice and can be developed with
resources(VAK, Train the Trainer, Toastmasters) andpractice.I better get started
now. 😀Mandatory
Techs
.map,.filter,.reduce)It seems the good soft skills is a must as you and others have pointed out.
Would it make sense to go more abstract and learn all Functional Programming (FP) concepts?
Hey Sung,
Soft Skills
I'm hesitant to call them "soft skills" because it makes them sound they aren't important to our job.
Lately, I've taken those skills to the next level, and great results.
If you can combine your tech skills with people skills, I think that makes you an unicorn. (You know that super awesome dev who is likeable and always be willing to help with a smile, yeah, that's who I am talking about).
HoF
I said because we are always doing list manipulation of some sort:
But for-loops can do the same? You may be thinking. And you are 100% correct, but HoF make def life much easier :)
Thank you for the explanations, Jose.
When I imagine the situation, I can see value of "people skill".
Regarding
HoF, I've been writing a series of blog posts (Sorry for the Shamless plug 😜) on implementing C#'s LINQ methods in JavaScript.I now know that it hasn't been in vein ☺️
Adding these to your arsenal might come in handy.
Thank you, Jishnu.
What I understood here is that skills don't have much to do with technologies but with underlying principles needed to build software nowadays (as it's not possible to keep up with everything).
Exactly! Technologies change rapidly. But if you are well versed in the underlying principles, you'll be able to build a solid software no matter what technology you are using.
I've always been a nano-pleb when it came to shell-editors. Somehow I never grew fond of Vim or Emacs.
Linux - Even after switching to macOS for mobile development, I still can use most commands here
Git - While I had a short stint with CVS, I basically used Git my whole career
SSH - I don't know too much about it, but I stopped using FTP after I found out about SSH on my first job
JavaScript - I did C at high school, C++ and Java at university and VBA and PHP in my first jobs, but since I started JS 7 years ago I use it for everything
Photoshop - I never was much of a PS-pro, but my PS skills somehow have proven quite timeless and useful for over 10 years now, even when using GIMP
Reading code - sounds obvious, but after switching to JavaScript all libraries and frameworks I used where open source, so I could read the code instead of asking on StackOverflow
Asking people why - often I tend to simply write down feature requests and try to blindly implement them, asking people why they need them often reveals that they are requesting the wrong thing.
How I understood was that basics of OS (linux), source control (git), security (SSH), language (javascript), etc will have a lasting impact throughout one's career.
Did I understand it correctly?
Yes.
But the basics of Git are much different than the basics of CVS. (distribution)
Also, the basics of JavaScript are also much different from other languages (more dynamic than most, event loop)
Thank you for the clarification, K :)
My skillset has several times been described as "arcane". I focus on:
1) things that don't change (Computer Science / math)
2) random bit of knowledge that I've picked up over my career
These seem to stick around and don't change a lot. The biggest skill I'm learning currently is networking; it is becoming more and more necessary, particularly if you want more work-life balance or other odd career choices.
Would you share how you are developing the
networkingskill?Is it something where one should just
show upat meetups?meetups are probably a good idea, particularly if you get to practice speaking. I am geographically isolated though, so the networking is a bit harder.
I am only considering networking here as in a professional context, so I try to measure two things: quantity and quality. Network size helps when making a big announcement and trying to get the word out. Network quality is immeasurable but probably more important than size in most cases. I think there are the two aspects of how capable some connection is of helping you, and then their willingness to do so.
Thank you Andrew for specifying the context and what to focus on.
I am blessed that NYC has many meetups I can learn and contribute to.
Thanks Patrick.
I can see how they can be used as new technologies are invented/discovered/created as they are the basics as @rhymes pointed out.
Understanding of some of the algorithms that sort of transcend our craft altogether.
All the stuff in the book Algorithms to Live By qualify in this regard. Essentially the "solved problems" of our world. The things you probably don't want to re-invent unless you know why you are.
Ooh, I've been looking for a new book - that sounds like an interesting read.
Thanks, Ben.
Skimmed thru the 1st chapter, and found
that this book demonstrates the importance of learning algorithms
and applying them in real life.
There's a few things that are important in construction projects, especially as applied to software:
Thanks Scott.
First two looks like it'll work for
build vs. buyproblem.Those two go hand-in-hand. When you're comfortable with those, you can clean up anything.
Would other *DD (BDD, ATDD, PDD[pain driven development 😝]) be substituted for
TDD?I see the differences as...
TDD is all about unit tests, which are written by the developers.
ATDD is all about acceptance tests, integration tests, bug regression tests, and system tests which are written by the testers.
BDD is all about software requirements described in a formal language, by the project owner or project manager, perhaps with the help of business analysts. The developers and testers are part of the collaboration & discussion, and the developers have to implement the nouns, verbs, and inquiries used by the BDD language (e.g., gherkin).
The big value of each is:
TDD: when the unit tests are written first, they help guide the developer write better code. Because the code will be unit test-able, which means it needs to be highly cohesive, and have no coupling, rely on no global state, and will be better designed. And for a very, very large system, the unit tests should run in a few seconds at most.
ATDD: automation of testing scales. The same tests can be run, repeatedly, and often. Likely will take hours, maybe days, to run the full suite of tests. Whereas, in comparison, manual testing does not scale - there's not enough testers in the world to test everything every time for every change for the entire system.
BDD: as the vocabulary of nouns, verbs, and inquiries grows, the PO/PM and BAs will be able to create novel behaviors because of the emergent expressive power. But moreso, the collaboration for shared understanding between the PO/PM, BAs, devs, and testers.
The way to ruin the value of each is:
TDD: write the tests after the code. At which time, then the tests are just being written for posterity as regression tests, and have lost 99% of the value of making them in the first place.
ATDD: have the developers write the tests. Because nothing hides a blind spot as much as having the person with the blind spot check for the things they can't see.
BDD: overloading the BDD system as a testers' platform for creating integration tests, bug regression tests, system tests, performance tests, security tests, et cetera. Or having the PO/PM abdicate responsibility for creating and owning the requirements in the formal language. Or by having the developers translate requirements from one system into the BDD language, and thus having to maintain two sets of requirements in two separate systems. Or by eliminating the meetings around BDD, which eliminates the key benefit to BDD.
TDD is a blanket term for all of those as far as I'm concerned (except PDD... sounds like the exact opposite). Writing automated tests before production code is what matters.
Thank you Hudson for clarifying ☁️ ➡️ 🌞 the intention behind TDD (
automated tests before production code) 👍