Ask HN: What is the most surprising technical skill you possess?
17 comments
Computer Programming.
I grew up in the C64/Apple II age when computers were cool and all, but still kinda toys. "Computer Programmer" was a job title, but not a very good one. Certainly not a well paid profession or one with any hope of advancement or prestige. The best you could hope for was a job in the basement at some Fortune 500 company or maybe scraping by at one of the little companies making video games or that "MicroSoft" place in Bellevue where they made "Mouse" and a few other things for PC clones.
So despite spending most of my youth getting really good at programming, it never occurred to me, even for a second, to study it at University or try to turn it into a career. The smart move for a smart guy was Engineering, so I'm officially a Mechanical Engineer by trade.
But then 1995 happened and suddenly Hello World + Angle Brackets was all the skill set you needed to name your price in the DotCom world. Suddenly all those years of building games where you pilot a little asterisk around the screen with a joystick shooting lower-case o's at things changed from being "waste of time" to "most valuable skill in the world", so I pivoted quick.
I never would have believed it had you told me. But I'm certainly glad it happened.
I grew up in the C64/Apple II age when computers were cool and all, but still kinda toys. "Computer Programmer" was a job title, but not a very good one. Certainly not a well paid profession or one with any hope of advancement or prestige. The best you could hope for was a job in the basement at some Fortune 500 company or maybe scraping by at one of the little companies making video games or that "MicroSoft" place in Bellevue where they made "Mouse" and a few other things for PC clones.
So despite spending most of my youth getting really good at programming, it never occurred to me, even for a second, to study it at University or try to turn it into a career. The smart move for a smart guy was Engineering, so I'm officially a Mechanical Engineer by trade.
But then 1995 happened and suddenly Hello World + Angle Brackets was all the skill set you needed to name your price in the DotCom world. Suddenly all those years of building games where you pilot a little asterisk around the screen with a joystick shooting lower-case o's at things changed from being "waste of time" to "most valuable skill in the world", so I pivoted quick.
I never would have believed it had you told me. But I'm certainly glad it happened.
Bravo. For folks who are listing soft skills, iirc the OP wants under-appreciated TECHNICAL skills.
Empathy.
It seems to be the basis for the small degree of mechanical sympathy I have because it makes me stop and think, 'why does someone else think this is the right way of doing things?'.
Good luck.
It seems to be the basis for the small degree of mechanical sympathy I have because it makes me stop and think, 'why does someone else think this is the right way of doing things?'.
Good luck.
It's really important in management. You can draw a line between the great and the bad managers based on emotional intelligence. It's not even about being a decent boss who cares about your people as humans, although I'm a big proponent of that too. Emotional intelligence is the "thing" that enables a manager to step back and consider why an idea that isn't his or her own might be the best path forward. In other words, empathy means allowing the people you've developed to impress you with what they know, rather than making them conform to your own ideas as a survival mechanism. If you go the latter, you better be brilliant, but even then the good people will leave you.
It's absolutely shocking how many people lack basic empathy when shit hits the fan. A lot of people are so quick to throw others under the bus if they make a mistake, as long as it saves their own ass.
Witnessing the lack of empathy has led me to follow my own advice of "don't be a dick" throughout my career, because being a dick has never helped. Here are some examples from only the last 5 years of my dev career:
1. While I was a junior developer I worked with a PM that would constantly ignore the advice of developers. She was the senior PM of the company, and would drive down every estimate given. If we said it'd take eight hours to build something, she'd drive it down to four because "the devs that used to work here used to be able to do it in four". When I became a senior developer at another company, she applied for a job there when one of our PM's was leaving, and after a chat with the MD about what it was like to work with her, he asked some other people he knew that'd worked with her. They all had the same story. She didn't get the job, and to my knowledge she's no longer a PM.
2. I was contracted out to work on an external clients work (I won't name them, but they're very big, you've definitely heard of them), and to cut a long story short, we were given a poor spec, no explanation of the project, and three weeks to get a site working. We managed to pass their tests, and deliver on time. They were given a generous about of time to raise bugs, but they went silent for a few weeks. On their go-live day, they called up at 5:30pm, demanding that we work over the weekend to fix the insane number of bugs they found, otherwise we'd not get any of our money. I fixed the bugs they raised (2 bugs, all minor) over the weekend, and their site went live on Sunday morning. Despite all of this, they said they weren't happy with the work (without a reason why, and in a very rude manner) and said they wouldn't pay. The company got a debt collector in, and got their money in the end, but the relationship between the companies was gone. A few years later, the offending company offered me a senior dev role, which I declined for this very reason. At my most recent job, the PM we spoke to who was very rude to us applied for an AM role, which we declined after I raised concerns about them. Finally, my old company had close ties with a number of freelancer groups in the area, and many of them directly heard about this companies attempt to squirrel out of paying their fee, alongside some other freelancers sharing similar stories. Now, many of the more established freelancers in the area won't touch them with a barge-pole.
3. I worked with an account manager that was ultimately blamed for a client wanting to leave us. I had a good working relationship with him, even though his role was ultimately to deliver stuff on time, and my role was to help drive development standards (the classic delivery versus tech one). A few of the other developers didn't, and were quite publicly vocal about how he pushed for delivery. I didn't agree with a lot of his decisions, but I kept it civil, as did some others. When he was let go, he freelanced at a few different companies, and those of us that kept it friendly still keep in touch with him. It's led to some of them receiving job offers by companies he freelances at, and him receiving tip-offs regarding leads for new clients. One of my old work colleagues moved to a company that is now his client, chose over the company we all used to work at.
I have a ton of other stories like this, where someone is a dick to another person, and it ultimately comes back to bite them in the ass in one way or another, even if they don't ever realise it. Treat people like decent human beings, and be humble. If a company or person is toxic, deal with them in a friendly way, but look to exit that relationship. If you're working with a junior dev that makes mistakes, be nice and help them as much as you can, because in the next 10 years you might end up working for them. Basically, don't be a dick.
Witnessing the lack of empathy has led me to follow my own advice of "don't be a dick" throughout my career, because being a dick has never helped. Here are some examples from only the last 5 years of my dev career:
1. While I was a junior developer I worked with a PM that would constantly ignore the advice of developers. She was the senior PM of the company, and would drive down every estimate given. If we said it'd take eight hours to build something, she'd drive it down to four because "the devs that used to work here used to be able to do it in four". When I became a senior developer at another company, she applied for a job there when one of our PM's was leaving, and after a chat with the MD about what it was like to work with her, he asked some other people he knew that'd worked with her. They all had the same story. She didn't get the job, and to my knowledge she's no longer a PM.
2. I was contracted out to work on an external clients work (I won't name them, but they're very big, you've definitely heard of them), and to cut a long story short, we were given a poor spec, no explanation of the project, and three weeks to get a site working. We managed to pass their tests, and deliver on time. They were given a generous about of time to raise bugs, but they went silent for a few weeks. On their go-live day, they called up at 5:30pm, demanding that we work over the weekend to fix the insane number of bugs they found, otherwise we'd not get any of our money. I fixed the bugs they raised (2 bugs, all minor) over the weekend, and their site went live on Sunday morning. Despite all of this, they said they weren't happy with the work (without a reason why, and in a very rude manner) and said they wouldn't pay. The company got a debt collector in, and got their money in the end, but the relationship between the companies was gone. A few years later, the offending company offered me a senior dev role, which I declined for this very reason. At my most recent job, the PM we spoke to who was very rude to us applied for an AM role, which we declined after I raised concerns about them. Finally, my old company had close ties with a number of freelancer groups in the area, and many of them directly heard about this companies attempt to squirrel out of paying their fee, alongside some other freelancers sharing similar stories. Now, many of the more established freelancers in the area won't touch them with a barge-pole.
3. I worked with an account manager that was ultimately blamed for a client wanting to leave us. I had a good working relationship with him, even though his role was ultimately to deliver stuff on time, and my role was to help drive development standards (the classic delivery versus tech one). A few of the other developers didn't, and were quite publicly vocal about how he pushed for delivery. I didn't agree with a lot of his decisions, but I kept it civil, as did some others. When he was let go, he freelanced at a few different companies, and those of us that kept it friendly still keep in touch with him. It's led to some of them receiving job offers by companies he freelances at, and him receiving tip-offs regarding leads for new clients. One of my old work colleagues moved to a company that is now his client, chose over the company we all used to work at.
I have a ton of other stories like this, where someone is a dick to another person, and it ultimately comes back to bite them in the ass in one way or another, even if they don't ever realise it. Treat people like decent human beings, and be humble. If a company or person is toxic, deal with them in a friendly way, but look to exit that relationship. If you're working with a junior dev that makes mistakes, be nice and help them as much as you can, because in the next 10 years you might end up working for them. Basically, don't be a dick.
I had something else in mind, but this certainly qualifies, and there is tremendous value for you, and "the greater good," in actively asking yourself that question. It adds perspective to the discussion as well. Thank you for the input.
Saw Myles Borins give a talk about Empathy on JSConf Iceland last week, one of the best talks of the conference and some really good points there.
The talk is not available online (yet!) but I know it will be soon at https://2016.jsconf.is/ but I found this talk by him which seems to be based around the same concept: https://www.youtube.com/watch?v=GKTSvI8qw_M
Can't recommend it highly enough.
Can't recommend it highly enough.
[deleted]
Just going to write this here so I can come across it days from now as I go through my comments as a good reminder to myself.
Well said.
Well said.
This was a surprising but well chosen skill to mention. Well done.
Understanding data. I've always had a fairly easy time learning core business processes and tying the data I'm looking at back to the activity that generated it. It's been really useful in managing analytics and data services because nothing I work with is a bunch of rows and columns without meaning to me, and as a result, I can deliver information based on what a given group is trying to accomplish (versus what they asked for, which is almost always different than what they actually need). It's also why I enjoy managing people. I usually bring on technically gifted people and help them learn the business, as that combination of skills has been the rarest thing of all for me to try and find when hiring. I work in a corner of the insurance industry that most consumers probably never see, but I like to think I make my own little impact when some of the people I develop move on to bigger and better things at companies we've all heard of. I know I'm off on a tangent, but if you're working in an analytic space, make time to learn the business and it will pay off in the long run.
I've been writing code since I was a kid, got an economics degree, then went to law school and practiced law for a while. Identifying objectives and finding the data that suits it has always been fun for me. Not surprising (to me, anyway), my career moved back from law to managing data and analytics as products.
I've been writing code since I was a kid, got an economics degree, then went to law school and practiced law for a while. Identifying objectives and finding the data that suits it has always been fun for me. Not surprising (to me, anyway), my career moved back from law to managing data and analytics as products.
+1 for tangent...I mean context, explanation and relevance. I appreciate the complete response.
I like my tangents. Occasionally I think I should try and keep it under control, but some of my best ideas have started off as tangents and eventually realized as root causes and such.
The ability to use Emacs with a decent degree of proficiency. I find its text navigation abilities beyond compare. This is huge for me since I write software and and the creation of software generally involves a lot of text manipulation. This is perhaps less of an edge now that other IDEs are better at autocomplete and jumping around the code than they were when I started learning Emacs.
On the other hand, the fact that I can write Windows applications, compile them using Microsoft's compiler, launch them, and follow their log files all within Emacs is wonderful.
So between the keybindings, 3rd party packages, and flexibility it not only makes me more productive but also helps me have more fun and stave off burnout.
(EDIT: Readability)
On the other hand, the fact that I can write Windows applications, compile them using Microsoft's compiler, launch them, and follow their log files all within Emacs is wonderful.
So between the keybindings, 3rd party packages, and flexibility it not only makes me more productive but also helps me have more fun and stave off burnout.
(EDIT: Readability)
This is a great example of what I had in mind when I asked the question. I used Emacs while exploring Lisp, and while I wouldn't claim proficiency, I have an appreciation for it's power.
Laziness - though of course when hiring you would bill it as efficiency or "expertise in software automation". A PhD taught me that often the best way to do things is the way that lets you press one button and have everything else happen automatically.
Mostly it's to make life easier, particularly when 2 months down the line you need to make a subtle code change and reprocess huge volumes of data. Being able to start a script and go to bed, rather than continually change the inputs, is a godsend.
I think this is likely a side effect of the "smart but lazy" geek trope, except actually taking advantage of it rather than procrastinating.
Mostly it's to make life easier, particularly when 2 months down the line you need to make a subtle code change and reprocess huge volumes of data. Being able to start a script and go to bed, rather than continually change the inputs, is a godsend.
I think this is likely a side effect of the "smart but lazy" geek trope, except actually taking advantage of it rather than procrastinating.
LOL
Pattern recognition.
When I started, all web development was server side preprocessing. This means debugging involved looking at thousands of lines of apache logs. After a while, you got good at picking out the lines you needed to see from the hundreds of lines of stuff you didn't care about.
This specific example isn't that relevant to today's web development processes, but being able to notice larger patterns in user behavior, in code use, etc is invaluable.
When I started, all web development was server side preprocessing. This means debugging involved looking at thousands of lines of apache logs. After a while, you got good at picking out the lines you needed to see from the hundreds of lines of stuff you didn't care about.
This specific example isn't that relevant to today's web development processes, but being able to notice larger patterns in user behavior, in code use, etc is invaluable.
Knowing how to use Google really well so I can find answers to bugs, tutorials, code snippets, etc. Learned the importance of this from a wise older Chinese programmer at my first job ever, an internship: "I don't really know how to code anything, I just copy it from Google."
I agree that being able to search effectively for information is an important skill - I do it quite a bit. But if someone doesn't really know how to code anything, doesn't that imply that they don't really understand how anything really works? And if you don't understand how something works, how can you fix it when something inevitably goes wrong?
Of course you have to understand how things work.
But in terms of getting things done, search engines can be amazingly helpful.
But if someone doesn't really know how to code anything, doesn't that imply that they don't really understand how anything really works?
Just because you know how to code doesn't mean you have to grind your gears doing root cause analysis on every obscure error message that bubbles up -- when about 80% of the time you can just paste the message into a search engine, and get a pretty good understanding within about 30 seconds. And save your precious grey matter-accessible calories for the other 20%.
In fact, in many roles you'd be crippling yourself (and wasting your employers money) if you didn't know how to use search engines effectively.
But in terms of getting things done, search engines can be amazingly helpful.
But if someone doesn't really know how to code anything, doesn't that imply that they don't really understand how anything really works?
Just because you know how to code doesn't mean you have to grind your gears doing root cause analysis on every obscure error message that bubbles up -- when about 80% of the time you can just paste the message into a search engine, and get a pretty good understanding within about 30 seconds. And save your precious grey matter-accessible calories for the other 20%.
In fact, in many roles you'd be crippling yourself (and wasting your employers money) if you didn't know how to use search engines effectively.
I've seen several references to Google magic. Give a quick tutorial or provide a couple examples? I know you can do things like +this or -that and other sort of basics for more precision. I'm guessing I've barely scratched the google search service. You guys are at Google Level 12 or something. :-)
I have found site:reddit.com can be good to restrict results to a certain site. Inurl: if you know a bit of text in the url. Filetype:pdf can be handy if you only want e.g. powerpoint presentations. Beyond that I think it is just knowing what things are called so you can search directly for things.
For open directories you can use intitle:index.of last.modified booktitle
For open directories you can use intitle:index.of last.modified booktitle
I don't think my skill is surprising but it is valuable nonetheless.
It is a willingness to see similarities instead of differences. This helps me write compact, clean code that is reliable.
It is a willingness to see similarities instead of differences. This helps me write compact, clean code that is reliable.
Love this question!
Most surprising in terms of unexpected returns: learning to build my own PC (Pentium 120MHz) at age 14 or 15 with parts from a local computer fair.
Searching and selecting the components and assembling everything by hand gave me a very personal connection to the machine and turned a complex thing in to something I felt I understood from first principles and could master and not be afraid of. I've always hand assembled my main PC ever since and I credit this ritual with all sorts of stuff:
- Getting me confident early on to experiment and play around with the machine knowing I could fix almost anything
- Keeping semi current with hardware over the years and getting an early view at the future (shift to almost limitless RAM, shift to multi-core, shift to SSD) - and the implications for the software I write.
- Understanding subtle hardware trade offs and constraints. This has helped countless times when I'm speccing out servers or infrastructure for the code I write (helps too when picking laptops !)
- Making it obvious, fun and easy to indulge in things like Raspis, OpenWRT etc.
- Providing endless jumping off points to burnish my understanding of the universe that makes up computing (different architectures, graphics subsystems, disk controllers, network fabrics etc)
- Getting me interested in the hardware and software history of computing and what it looked like 20,30,40,50 years ago. This has helped me hugely in understanding why things today are the way they are (programming languages, operating systems, software abstractions etc)
That's just off the top of my head :)
Most surprising in terms of unexpected returns: learning to build my own PC (Pentium 120MHz) at age 14 or 15 with parts from a local computer fair.
Searching and selecting the components and assembling everything by hand gave me a very personal connection to the machine and turned a complex thing in to something I felt I understood from first principles and could master and not be afraid of. I've always hand assembled my main PC ever since and I credit this ritual with all sorts of stuff:
- Getting me confident early on to experiment and play around with the machine knowing I could fix almost anything
- Keeping semi current with hardware over the years and getting an early view at the future (shift to almost limitless RAM, shift to multi-core, shift to SSD) - and the implications for the software I write.
- Understanding subtle hardware trade offs and constraints. This has helped countless times when I'm speccing out servers or infrastructure for the code I write (helps too when picking laptops !)
- Making it obvious, fun and easy to indulge in things like Raspis, OpenWRT etc.
- Providing endless jumping off points to burnish my understanding of the universe that makes up computing (different architectures, graphics subsystems, disk controllers, network fabrics etc)
- Getting me interested in the hardware and software history of computing and what it looked like 20,30,40,50 years ago. This has helped me hugely in understanding why things today are the way they are (programming languages, operating systems, software abstractions etc)
That's just off the top of my head :)
Debugging and the intuition for finding the cause of a problem. Well, part intuition and part efficiency and pragmatism in following clues but not getting stuck on bad leads. Willingness to go down in the muck with gdb and to go back up again and consider workarounds and rewrites or whatever it takes to fix the problem as cleanly and quickly as possible.
Another skill is learning my way around a code base even in an unfamiliar language in a very short time, through a process of intense grepping, skimming, guessing, taking notes, and so on.
Also a polyglot attitude that frees me from worrying too much about which language is good and which is evil, and lets me work happily with all of them. That's related to how I use Emacs without language modes (except paredit in Lisp) so I never have to configure modes or colors or whatever.
Another skill is learning my way around a code base even in an unfamiliar language in a very short time, through a process of intense grepping, skimming, guessing, taking notes, and so on.
Also a polyglot attitude that frees me from worrying too much about which language is good and which is evil, and lets me work happily with all of them. That's related to how I use Emacs without language modes (except paredit in Lisp) so I never have to configure modes or colors or whatever.
Self learning, being able to pick up a book and learn something new. My university had a trimester system, and everything was fast paced. My university really pushed this skill being on a trimester system.
Empathizing, giving people the benefit of doubt and assuming good intentions.
The believe that you can accomplish anything, just divide and conquer.
So your super power is self confidence? :-)
I'm serious. That IS useful.
I'm serious. That IS useful.
I am able to crash any piece of software or hardware.
I still don't know if this is a superpower but it helps a lot when designing stuff.
Same here, this power in invaluable to me while I was working as a software tester previously.
Synthesizing information or ideas into something useful, such as a complete solution to a problem.
The emphasis here is on practical usage/benefit (productivity, efficiency, simplicity, etc.).
By surprising, I mean what has shown you the greatest returns, though it was not an emphasis in a curriculum or hiring.
For example, something you learned when you were 12 you found not many people understand or use, but has served great productivity. Or it could be something that everyone knows, but doesn't use because of a trend, or some other reason.
It could be a language or a tool, just something technical that you never realized would be so useful.