Evergreen skills to use throughout your career?

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.

Software Development: Some Things Never Change

Alex Fawkes for CheckGit ・ Dec 13 '18

#software #softwaredevelopment #softwareengineering #softwarearchitecture

Comments

[mikerg]

• 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

[Unfrozen Caveman Dev]

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.

[mgaruccio]

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.

[Unfrozen Caveman Dev]

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.

[Harish Sharma]

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.:)

[Sung M. Kim]

Thank you, Mike.
Those are valuable skill sets that we can apply for our lives, as well.

[Le Xuan Trung]

Thank you for your sharing.

[Douglas McKechie]

Based on my own experience these have been some evergreen skills...

• Relational Database Design and understanding, some SQL as well
• Object Orientated theory such as Classes and Inheritance, properties and methods
• How to think about and program solutions in a C-flavoured language, for example C++, PHP, JavaScript, C#, even Python - I have found it very easy to transition between these languages when needed
• Raw Javascript - while frameworks are nice, knowing what can be done in plain old JS is quite helpful I think
• Basic Photo editing skills. Crop, rotate, resize, possibly clone and heal too (useful in my field of web development)
• How to listen and talk with non-technical people
• Training, both written and verbal, so you can effectively teach people how to use products you have developed

[Sung M. Kim]

• How to listen and talk with non-technical people
• Training, both written and verbal, so you can effectively teach people how to use products you have developed

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?

[Douglas McKechie]

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.

[Sung M. Kim]

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) and practice.

I better get started now. 😀

[Jose Gonzalez]

Mandatory

• Listening
• Communicating clearly
• Ego check
• Empathy
• Remembering that you are not your code

Techs

• CRUD
• N-Tier architecture
• High Order Functions (.map, .filter, .reduce)
• Know how to google a question (dead serious)
• Have friends who are experts in specific topics so you can ask them questions (and also pay back by helping them)

[Sung M. Kim]

It seems the good soft skills is a must as you and others have pointed out.

High Order Functions (.map, .filter, .reduce)

Would it make sense to go more abstract and learn all Functional Programming (FP) concepts?

Know how to google a question (dead serious)
I got an idea on how from Shawn Wang (How to Google Your Errors)

[Jose Gonzalez]

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:

• A list of items (data retrieval)
• I want to create a new list of items from those items (map)
• I want a subset of that list of items (filter)
• I want to find the total price of those items (reduce?)

But for-loops can do the same? You may be thinking. And you are 100% correct, but HoF make def life much easier :)

[Sung M. Kim]

Thank you for the explanations, Jose.

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

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 ☺️

[Jishnu Vasanth]

Adding these to your arsenal might come in handy.

• Design patterns like MVC, MVVM, singleton and abstract factory.
• Programming paradigms like object-oriented and procedure-oriented.
• Design principles such as SOLID, KISS, DRY and YAGNI.
• Coding conventions and standards such as usage of whitespace and comments, naming variables and functions.
• Collaboration and working as a team.
• Software Development Life Cycle and knowledge of software development frameworks such as Scrum, Kanban, Lean, and Extreme Programming.
• Writing maintainable, scalable and robust code.

[Sung M. Kim]

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).

[Jishnu Vasanth]

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.

[K]

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.

[Sung M. Kim]

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?

[K]

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)

[Sung M. Kim]

Thank you for the clarification, K :)

[Andrew Lucker]

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.

[Sung M. Kim]

Would you share how you are developing the networking skill?
Is it something where one should just show up at meetups?

[Andrew Lucker]

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.

[Sung M. Kim]

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.

[Patrick Minton]

• Git
• SQL and relational databases in general
• Algorithm Complexity (the basics: you don't have to know everything about every sort algorithm, but if you understand the basics, you will avoid many mistakes that many developers make, because you will know WHY some code is less efficient than others -- and when it matters)
• Functions: Functions are in all languages. Understand things like function purity (when and why it matters), idempotency, etc.

[Sung M. Kim]

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.

[Ben Halpern]

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.

[goyder]

Ooh, I've been looking for a new book - that sounds like an interesting read.

[Sung M. Kim]

Thanks, Ben.

Skimmed thru the 1st chapter, and found
that this book demonstrates the importance of learning algorithms
and applying them in real life.

[Scott Tadman]

There's a few things that are important in construction projects, especially as applied to software:

• Knowing what's easy, what's difficult, and what's possible.
• Estimating how long something will take, and how much it will cost.
• Setting priorities, knowing what's important, what's secondary, and what's a distraction.
• Anticipating failures and having back-up plans.
• Working within given constraints to achieve the best outcome.

[Sung M. Kim]

Thanks Scott.

First two looks like it'll work for build vs. buy problem.

[Hudson Burgess]

• TDD
• Refactoring

Those two go hand-in-hand. When you're comfortable with those, you can clean up anything.

[Sung M. Kim]

Would other *DD (BDD, ATDD, PDD[pain driven development 😝]) be substituted for TDD?

[Eljay-Adobe]

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.

[Hudson Burgess]

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.

[Sung M. Kim]

Thank you Hudson for clarifying ☁️ ➡️ 🌞 the intention behind TDD (automated tests before production code) 👍