My first idea is to improve the way and how much I use the keyboard with the final goal of typing faster and use the mouse less (my wrist will be happy about that).
Is there any other everyday skill you think is important to master? Any advice on how to improve it?
There is an art to writing concise, accurate text that someone can easily follow. Very few people are capable of this, and those that can have a serious advantage in their career trajectory.
It doesn't matter what you know, if you can't explain it to someone else.
You make money by being able to do things other people can't do, or won't do. Most programmers won't or can't learn to do these well, so those that do get a very big leg up. When execs and owners try to figure out who should become dev leads, managers, CTOs, etc, they will be looking for these skills in addition to technical chops.
I can't stress this point enough. Learn to write product plans. Documentation that delights people being onboarded to new systems is always appreciated, often by yourself months -- or years -- later. Well written bug reports, feature request, and such can easily cut developer turn-around time in half.
And to add one more thing: humility. Be the type of person nobody >needs< to listen to because they can so clearly follow you by example.
To people downvoting this, think back when you were last annoyed by bad or even missing documentation. I bet this was very recently, if not today.
I completely agree with you but it seems pretty hard to hone that skill if there's no one to give you feedback.
e.g. you write some internal docs but then no one lets you know how could they be more useful/understandable, until someone else comes and re-writes the docs.
Also write. Write a lot. And ask for help. If you work with/know someone who is considered a good tech writer, I bet they will help you.
write a blog post about stupid pointless problems you solved. and make that blog post useful for anyone who came accross that problem.
It is useless. But it is good practice for you, because being able to write technical documents that are easy to follow is highly valuable.
Oh and get everyone you know to criticize it like a code review :)
In regards to learning itself.
- Trying to be open to any language, stack or technology concept or paradigm. And be devoid of fanboyism. Pick no favourites but trying really to look at the broad spectrum of software development. See what different paradigms bring to the table.
- Be good at discussing technology with people and listening to them. Learn to communicate in an open manner, ask 'Why', 'How would you solve X' instead of 'That won't work' when you are unsure of the ideas of others.
- Try not to search for affirmation but try to find honest discussions.
- Leave your ego behind
- Become good at selecting which whom you discuss with, and divide your energy and attention accordingly. I.e I usually have more meaningful discussions with people that tried a lot of different paradigms, technologies and finally settled at some stack.
- Understand that sometimes you choose a lesser technical thing or solution, because the team can't work with it yet. - Become good at dissecting hype, but be open minded and not bitter.
- If you want to grow hang out with people that are better then you and learn a lot from them.
- Learn how to learn.
- Keep a learning log/diary for yourself. For reference and to see how far you've become.
- Find the right attitude and motivation for learning. Try not to think I can't do this. But think. In 3 years I'll be able to do X y z. I can still suck a little for 2 years hurray!
The biggest bang-for-your-buck skill to learn as a software developer is delving one level below what you're working at and learning enough about how it works so that you can debug effectively. It will also expand your horizons so that you can see more possibilities than the next guy. Problem solving is the bread and butter of the software developer.
It's similar for players of instruments. Proper posture and hand position will greatly help in playing the more difficult passages, but it's the muscle memory that allows you to play without thinking (regardless of posture or hand position).
While hand position does matter for playing an instrument well, it's far less important on a keyboard you spend 10% of your time typing on.
Know when to leave a bad situation. And make sure you don't work too hard. If you work too hard you can be perceived as showing off, and make others feel insecure. I'd even argue it's better to work too little than to try to constantly upstage people. If you're trying to upstage your boss or your coworkers they'll try to get rid of you. If you're not doing all that much, assuming you're not a complete jerk they'll first try to help you get back on track, and if not you can probably hang out a bit longer while they work through the process of finding a replacement.
But seriously if you're a jerk, you'll be fired and they might not even care to find a replacement.
- Mentoring
- Outsourcing my thoughts to discussions with other engineers. Help leverage their knowledge, and help myself.
- Thinking about error handling when integrating 2 systems. Expecting failure should be part of the solution.
- Making systems that are designed in the "there are obviously no problems" vs "there are no obvious problems" which I have succeeded in various degrees. Every time I hit the latter I get sad that I failed.
- Knowing when a test is absolutely critical, and when one is optional.
- Knowing how to abstract better, into more testable code.
- Knowing what "project ownership" means and practicing it heavily.
Honestly, I still use the mouse _A LOT_. I don't use VIM for coding, I like it but I prefer JetBrains for everything.
Listening/observing because you really need to understand why you build what you build and depending on what you are building you'll only figure out the "why?" if you listen / observe deeply without preconceived notions. I've tried to improve this skill for years and still struggle with it!
Writing because once you've absorbed the information, you need to synthesise it and there is no better way to challenge your own thinking than writing. I always thought I was good at writing until I read a few books about writing skills and then read a few books (both fiction and non-fiction) and assessed the quality of writing with these basic ideas in mind. Only then did I realise that I suck at writing. It's really hard to write well, but if you can write well you have the most powerful tool at your disposal as it can scale the thoughts and ideas of one individual to millions or even billions of people. It might also just convince a bunch of teammates to follow your lead :)
Mind sharing the titles?
"On Writing Well" by William Zissner
"The Elements of Style" by William Strunk Jr., E.B. White
"Stein on Writing" by Sol Stein
"Self-editing for Fiction Writers" by Dave King
Learn to actively listen to what people are saying, what they don't say, and, most importantly, what they mean.
This will serve you in any career, but software devs who can grok what is meant rather than what is said are especially valuable.
Why? Because so much of what we deal with are abstractions that can be slippery and mean different things to different people. Getting a firm grasp on everyone's meanings is crucial to bridging divides and delivering value.
(I know you said soft skills, but the poster you responded to talked about stuff closer to social skills than soft skills.)
HOW they get it done is less important. Knowing WHO is most capable and whether the task should be automated is sometimes more important than implementing a solution yourself.
I always try to spend the most time on learning higher conceptual things. There are so many things that are written about, most of them are either already known/practiced, not such a big deal, or so poorly described as not to be of use. Whenever I come across one that I can't make sense of, that's what I try to understand. Of all the 'patterns' I've read or used, the one about policy vs mechanism was one that read like 'ok that seems good' but I couldn't recall consciously applying. After thinking on that a good long while, it's now becoming internalized and I see it everywhere, or clearly see where it could have been used to good effect and wasn't. In practice, it basically comes down to building an elemental set of capabilities or facilities that can then be flexibly combined to make the feature(s) you want to deliver.
The best every day skill is having a style of code that conveys the important ideas in small parts without having to hunt around and reverse-engineer the idea that should have been conveyed. This is usually through a good choice of 'factors' when you refactor and giving an disproportionate amount of time naming things and mentally reading it back to see what another developer might think from reading it.
After that communication skills are huge. You'll almost never work in total isolation. The better you can communicate the greater bandwidth you'll have with the rest of your team and customers. That bandwidth will bottle neck you far more than typing speed.
Unless you are not touch typing yet. That is a must. If for nothing other than comfort.
Get an ambidextrous mouse, and try left mousing from time to time. Try to left mouse at work, and right mouse at home to give your body more variety. Use page up/page down to scroll instead of the scroll wheel; scroll wheels are super useful, but ergo nightmares.
But, that's not going to help your work that much. Work on effective communication, which is gathering information from others as much as it is providing information to others. Sometimes the other is yourself. When you see some writing or speaking or drawing that communicates well to you, study it, and think about how you would have done it, and what you can do differently to be more effective. Practice this as well. Maybe you see a manual that's terrible. Can you spend 30 minutes redrafting it and another 30 minutes communicating with the owner to get it updated?
- Learn to learn. This touches every facet of being a SWE. There's a clear difference between a SWE who has spent their entire career in one language and one domain and a polyglot engineer who just has a taste for understanding things in the world and implementing them. Of course, this generates a lot of shallow knowledge, so know yourself and seek improvement where possible.
- Listening and understanding. You're going to hear a lot of inaccurate things from users, peers, etc -- learn to ask the questions that bubble the core concerns up and listen for the things that aren't being said.
- Know your audience. The other day my friend sent me a screenshot of a network technician asking her (a teacher) about a demarcation point. Although technical (and often mathematical terms) are appropriate for use between engineers you know with a common understanding, they're not appropriate when dealing with people outside of the scope of technical work.
For using the keyboard exclusively, I would recommend using the text editor Emacs which is very old (as old as linux?) and very stable, has keyboard actions for moving up and down by row, across by any number of characters, switching between buffers, and even has a built-in "undo tree" that you can walk back and forth to see code changes very easily.
Emacs is much, much older than Linux. The original Emacs was written in 1976. Gosling Emacs, the first Emacs to run on Unix, was written in 1981. Gnu Emacs was written by Stallman in 1984.[1]
Linux was first released many years later, in 1991.[2]
* data structures. Some developers can grasp that data facets are composed into groups called structures internally divisible by something called relationships. Other developers don’t ever grasp that and simply view the world as a stream of search queries.
I know, I know, but someone's gotta do it.
2. How to ask the right questions - and how to ask them correctly. The clearer you are able to convey which information you are looking for, the less you will be sent on wild goose chases.
3. How to use Google well.
4. How to take a step back, relax, and refocus.
I'll write an email that describes the high level objectives and the strategy I think will lead to success, then describe why I think it is true, then describe the hurdles, and then go deeper for what needs to happen right to the issue number on our issue tracker, and a pesky line of code or pull request on a third-party library.
Everyone has a receptor to bind to or a port to plug into.
It is also useful to write the "bottom line up front", or "BLUF"[0]. Conclusion, then the underlying research and data that lead you to reach that conclusion. If there are actions people need to take, write those at the top properly tagging the people who need to do them.
Another useful "skill" is "problem solving". We're a tiny boutique consultancy specializing in machine learning, and we have good outcomes working with our clients because we spend the necessary time to extract the problem out of our clients and clearly define it, and then solve that problem. We're not "AI enthusiasts/influencers" and we don't shy away from telling clients they don't need machine learning for the problem we identified. We've been approached by many who want the stereotypical "AI blockchain IoT" and we don't like solutionism.
Books:
- "General Methods for Solving Physics Problems". It is a book that recognized the problem many students have: they know the formulas and laws but they don't where to apply them, when, and how to know what a problem is, or when a problem is solved. Its definitions are delightful.
- "The Complete Problem Solver" by John R. Hayes. The book This is not a quizz collection, but an abstract way to think about problems, and then practical techniques to solve them.
- I recently discovered a book titled "Cracked It!: How to Solve Big Problems and Sell Solutions Like Top Strategy Consultants". I only skimmed the table of contents for now and seen the authors talk about it, and it looks like what we do with clients.
- "Change by Design" by Tim Brown. There are many useful concepts in there, but that also describes our approach, especially when they talk about "desirability, feasibility, viability".
Finding the right questions to ask, identifying the problem, then solving it will save you.
The skill of reading and synthesis is useful when diving deep in a domain. We work in diverse sectors and industries, and we must quickly be able to communicate with domain experts to define problems and find solutions. There's a large amount of reading and understanding to do. That is valuable for the project itself, but also for subsequent projects.
Another extremely useful skill is interviewing. We talk a lot with domain experts, and we must know how to extract problems from what they describe, frame the conversation, drive them to explain more, etc.
Generally speaking, there are many skills like design, "business", sales, marketing, that are very useulf.
> Any programmer wishing to be a great programmer should read this! https://www.amazon.com/Things-Every-Programmer-Should-Know/d...
This book is an assemblage of short papers running on themes as different as Bugs, Error Handling, Customers, Refactoring, and Expertise.
The motivation behind the short exposition isn't to address every one of your inquiries or be an authoritative manual for programming.
