Ask HN: What is the most surprising technical skill you possess?
I'm hoping to get responses from a programmer's perspective.
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.
36 comments
[ 5.1 ms ] story [ 83.8 ms ] threadIt 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.
Can't recommend it highly enough.
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 muc...
Well said.
It is a willingness to see similarities instead of differences. This helps me write compact, clean code that is reliable.
https://www.youtube.com/watch?v=cpYoQfhk37s
God says... ping condescending takeover formlessness enshrouds tildes Americanization's Canaries doxology solution growl Sahara clavicle's sustenance's tensed skill handstand consigned katydid's sealskin's fricassee's Styx's itemize telexing nonflammable wryness wrists topside shouldn't cajolery's curlycue muskrats
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.
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.
For open directories you can use intitle:index.of last.modified booktitle
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)
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.
I'm serious. That IS useful.
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 :)
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.
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.
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.