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 ・ Dec 13 '18 ・ 5 min read

#software #softwaredevelopment #softwareengineering #softwarearchitecture

Comments

[drubb]

Patience

[Raymond Price]

• Messing around with Git. You don't need a lot of heavy wizardry, like doing an octopus merge or whatever, but the ability to do interactive rebases and cherry-pick commits is extremely useful regardless of whatever language or project you're working on.
• Debugging. Again, there's a lot of depth, but as long as you can at least set a breakpoint and follow a bug through there, you should be good.

[Order & Chaos Creative]

Logic

[Sung M. Kim]

Simple yet hard to master

[Ben Sinclair]

How to write a concise, informative and useful bug report.

[Sung M. Kim]

Thanks Ben.

I wrote about creating a GitHub issue template to provide information required for a bug report.

Providing a Better GitHub Issue Experience

Sung Kim

#github#opensource

Would requiring following info too much?

How to reproduce the error
An expected behavior
Environment such as browser, versions, and
additional (optional) contexts such as screenshots/videos.

[Ghost]

Learn how to solve problems by linking the correct solution.

After 35 years in this business the one nugget of advice I would pass on to you is this. Languages, Architectures, and Paradigms are all JUST TOOLS. Pick the right tool for the right job. Don't crumble under the pressure of evangelists (AKA fan-boys/girls) and try and make a language or technology fit the problem.

[Sung M. Kim]

Thanks Mike.

Pick the right tool for the right job
I believe 👆 sums it up 😎

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

[andrew]

clean code and clean architecture

[Alain Van Hout]

Maintainability, practicality and business sense. All the rest tends to be details.

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

[Attila Max Ruf]

• anger management
• being able to work without frameworks so you don't rely on them, but use them as a basis for your ideas
• basic understanding of patterns and principles. i think this is extremely important. not just knowing, but understanding the motivation behind a pattern's existence and the foundation of them. this makes code appear less magical
• being able to adapt fast to changes like B.O.R.G.
• don't be picky. every environment has its beauty once you get to understand it.

[chatelao]

Windows/Office knowledge:

• Winword / Excel / Outlook
• Including shortcuts for navigation

SQL / XML / Encoding

A memory of all failed Projects

Listen to my guts

[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) 👍

[JeffD]

"Human communication protocols": as said by @mikerg , @dougmckechie , @jishvi (for mails, team, reports, talks ...) and how to improve your "team happiness" (communication, gifts, event, training, ...)

"Low-level communication protocols": HTTP/HTPPv2, NTP, DNS, ...

"Application/microservices communication protocols": Rest, SOAP, SQL, graphQL, Ajax, ...

[Sung M. Kim]

Now the question I have is,
how low is too low?

Is going down to assembler/machine language level too low? Or should a developer have a knowledge on electrical engineering?

Not sure where to draw the line 🤔

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

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