Ask HN: Which everyday skill is important to master as a software developer?

41 点作者 atosatto大约 4 年前

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?

23 条评论

thomascgalvin大约 4 年前

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.

评论 #26115741 未加载

评论 #26114779 未加载

评论 #26114821 未加载

评论 #26115069 未加载

评论 #26114835 未加载

technicolorwhat大约 4 年前

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!

kstenerud大约 4 年前

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.

评论 #26114285 未加载

offtop5大约 4 年前

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.

Justsignedup大约 4 年前

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.

评论 #26115256 未加载

JulianRaphael大约 4 年前

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

评论 #26115774 未加载

评论 #26117097 未加载

mooreds大约 4 年前

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.

评论 #26122992 未加载

tuckerpo大约 4 年前

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.

评论 #26115282 未加载

ctocoder大约 4 年前

Spending time with friends and family.

评论 #26115150 未加载

karmakaze大约 4 年前

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.

xupybd大约 4 年前

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.

toast0大约 4 年前

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?

kodah大约 4 年前

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.

ochronus大约 4 年前

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: <a href="https://ochronus.online/communication-for-software-engineers/" rel="nofollow">https://ochronus.online/communication-for-software-engineers...</a>

sova大约 4 年前

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.

评论 #26121274 未加载

austincheney大约 4 年前

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

yannoninator大约 4 年前

Implementing algorithms.I know, I know, but someone's gotta do it.

DocTomoe大约 4 年前

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.

tkinom大约 4 年前

Able to write full automated system level regression tests for every platforms/app/system you develop for.

simplecto大约 4 年前

You need to reach out to this guy. Hes written a book on the subject.<a href="https://themouseless.dev/" rel="nofollow">https://themouseless.dev/</a>

Jugurtha大约 4 年前

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.- [0]: <a href="https://en.wikipedia.org/wiki/BLUF_(communication)" rel="nofollow">https://en.wikipedia.org/wiki/BLUF_(communication)</a>

watan0000大约 4 年前

notoriousarun大约 4 年前

> 97 Things Every Programmer Should Know> Any programmer wishing to be a great programmer should read this! <a href="https://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484?dchild=1&keywords=97+things+every+programmer&qid=1613143781&s=books&sr=1-1&linkCode=ll1&tag=amazonpurch08-20&linkId=d9f3275fb664f9fa5c7c92dae928d0f6&language=en_US&ref_=as_li_ss_tl" rel="nofollow">https://www.amazon.com/Things-Every-Programmer-Should-Know/d...</a>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.