Ask HN: Which everyday skill is important to master as a software developer?
I'm a software developer who recently started to work 4 days a week and consequentially I have some free time I want to dedicate to self improvement. I'm not looking to learn new programming languages or framework, but I just want to learn or improve code agnostic skills to do my work more efficiently.
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? Writing, especially technical writing. 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. This. And then nearly equal in importance (or maybe more depending on your position), speaking. If you can code well, write clearly, and cogently argue your case without being a jerk about it, you will do well in the software business. Join toastmasters for at least a year. 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. 'Speaking' has my vote over 'Writing'. If something is not clear then people turn to 'talking' I agree on the order of importance, to be honest. But being able to write well really helps one's speaking too. A shame to see this downvoted. I presume its because of the "Very few people are capable of this" bit? 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. This a very important skill, especially for lead devs. 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. Any recommendations on resources to learn/improve this skill? 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. Read. Read a lot. Look for successful documents and emulate their patterns. First, understand what the author was trying to accomplish with the doc, then study the structure of the doc, then dig into the language choices. But, if I had to pick one thing to study, it would be structure. I frequently read tech docs that come off as a stream of consciousness. You have to understand your audience and put the effort in to give them context (the problem, the requirements, the methodology) before giving them the solution. 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. Also learn how to diagram and do quick mock-ups. Visuals can help bridge the gap between what you can articulate and what the reader needs to develop a good mental model of the proposal. [this comment is coming from someone who writes mostly technical design documents needing to communicate a technical solution to a problem while also considering multiple alternatives] Read the book On Writing Well by William Zinsser. Do some teaching / tutoring. You will get useful feedback by observing whether your students understand your explanations. Thanks for the ideas! this. 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 :) I learned the most actually from discussing with others. Also I learned a lot from doing a lot. I.e. ideation, sales, putting in production, maintaining, upgrading, documentation, and sunsetting. This removes one from a tunnel vision that I used to be in, seeing things in broader scope. 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! Typing speed beyond an intermediate level will not improve your software development prowess. The more experience you gain, the less of your time developing will be spent hitting keys on the keyboard. If you're spending more than 10% of your time typing, you're probably not thinking enough. 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. Not answering your question, I have asked HN about keyboard layout: https://news.ycombinator.com/item?id=26112993 . As a touch typist, I think that ability to use keyboard without looking at is a great skill in any use of computers. It is not about time spending, it is about ability to think and typing simultaniously without interrupting the process of viewing code. Yes, that's a common belief, but what's really freeing up your mind to think and type simultaneously is the muscle memory, which doesn't actually require touch-typing. 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. There is nothing wrong in the muscle memory point, but the key point is different. Whether you DISTRACT or NOT DISTRACT from your lines of code? Do you spend some extra energy for returning your view to your line of code or not spend? Are you able to free your visual stream into your brain from seing keyboard or not able? Look at Vim workflow, one of the most popular editor for programmers, its command mode seems absolutely pesky for those who not touchtypes. I don't view code as lines, but rather as chunks of logic. When I'm writing, I don't need to see what's on the screen because I already know how it is; the task is transforming it into how I want it to be. The process goes: thinking (5-10 minutes), typing (30 secs to a minute), thinking, typing. Most of the time I'm not even looking at the screen, even when typing. The typing part is just writing the stream of completed thoughts to the computer. Know how to manage your stress levels. 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. Things that have made me a better programmer: - 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. What does project ownership mean to you? Listening/observing and writing. 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 :) Agreed! Just posted about active listening today https://ochronus.online/active-listening-boosts-careers/ > I read a few books about writing skills Mind sharing the titles? Sure! "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 Listening is what I would pick. 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. Soft skills. Make a point to talk to almost everyone.
Most companies are not meritocracies. If you wanna get ahead, you have to know how to schmooze. They are not so unmeritocratic as all that. Soft skills are a key part of merit. It is much more common to over value social skills than to under value them though, as you are biased in favour of those you like. At some point someone has to produce something of value, and having tons of people around whose only good quality are their great social skills doesn't help, they are leeches in that scenario and their social skills makes them hard to remove. They create similar inefficiency problems as the people who lack social skills entirely and sit on their own writing a huge messy system only they understand. Replacing competent people with likeable people is a common way for companies to rot. (I know you said soft skills, but the poster you responded to talked about stuff closer to social skills than soft skills.) Knowing you can rely on somebody to understand and handle a problem is what matters in an organization. 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. Spending time with friends and family. I have also spent (too much) time on improving my typing--custom layouts etc--even though I was already a proficient touch typist. I realized I do way more thinking than typing and there's little benefit in productivity. I've stuck with it in the hope that it avoids RSI in the future. 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. Being a software developer often means you have to use your skills to solve problems in domains outside of software development. Mastering the domain you work in makes life so much easier. 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. Good keyboarding skills are useful, but also pretty easy. Spend an hour or two reading and watching about how to do it properly, and then spend 30 minutes a day on PAWS, Mavis Beacon, Mario Teaches Typing, Typershark or The Typing of the Dead for maybe a month. Paying attention to your posture and proper technique more than everything else. Put a (paper) file folder over your hands so you can't peek. 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? A couple that come to mind: - 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. Definitely communication (I know, a broad category)! Teamplay is key and good communication is the foundation of that. I've written a bit about this: https://ochronus.online/communication-for-software-engineers... Brainstorming and mapping out your ideas and concepts before diving in to code are very fundamental to an expert workflow. I would recommend getting a notebook with dots or gridlines for modeling out creative tasks, and getting a dry-erase board and some fine-tip dry-erase markers for quick drawing and task management. 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 which is very old (as old as linux?) 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] * technical writing. There is a night and day difference between people who can balance brevity and precision and those who can’t. It’s like separating the adults from the children in the room. * 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. Implementing algorithms. I know, I know, but someone's gotta do it. 1. People Skills - you can be the whizkid, but if you cannot relate and talk to the end user, your product will be worse off, and you will likely be out of a job soon. 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. Able to write full automated system level regression tests for every platforms/app/system you develop for. You need to reach out to this guy. Hes written a book on the subject. Writing people can understand and act on. Writing that ties several threads and abstraction levels when different audiences will be consuming it. For example, when writing an email and the recipients are executives, managers, sales people, engineers, advisors, and advisors, I write what I call "fractal communication": an email that makes sense at different abstraction and "zoom" levels. A pre-requisite to do this is to know your audience and what matters to them, and how they view things. 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. hi > 97 Things Every Programmer Should Know > 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.