I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact thing. He argued that what I as working on was a waste of time and that I shouldn't work on "code golf" problems, because of the likelihood of failure and that ultimately I should consider the human side of the problem. He said it was best to work on other things instead.
Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop.
My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.
30+ years here, so I'm just a youngster compared to you, but yes, that seems to get lost.
My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.
His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".
He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.
I think this applies to not just software, but engineering in general. See, science is mostly about observing the natural phenomena. On the other hand, there are jobs that are mostly about taking care of people's needs. Engineering sits in the middle. It's a mediator. We have to understand the circumstance of both sides - nature (this could be something like hardware capacity in our case) AND people. Just taking care of one side makes you a bad engineer. You need to be technical and sympathetic at the same time.
Approching the same experience level and fully agree.
A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.
The biggest mistake people in our industry make is thinking they are somehow exempt from the rules of society and business just because they can use a computer better than most people.
Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.
What's the quote? Knowledge can be taught. Wisdom can't be taught or told... it can only be learned through experience?
Edit: Ah, found it.
"Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha
Software is whatever you want it to be. I can write software that is not for other humans. That's the most fun part of software engineering to me, when you don't care about the users and just do it just for the fun of doing it.
Can't agree with this enough. Sometimes it is directly for other humans (a GUI), other times it is indirectly related (an ETL job that converts data into a form that can be easily used to drive a recommendation engine which provides recommendations ... to people).
This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.
Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.
> Software is a social service. Its for other humans.
I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!"
You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imho its a highly toxic sentiment to think that whatever a programmer does is for other humans. Software as a Social Service...SAAS :)
imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans. Not as a social service. In fact all the people I deeply admire in the software world - Arthur Whitney, Kenneth Iverson, Mattis & Kimball, Perlis, Dijkstra, hell even Linus, are generally characterized as egotistical assholes in the public space who really don't give a flying fuck about social service & humans but care deeply about the software they created for their own selfish reasons.
Mattis is quite explicit about this - "You should understand that the GIMP and GTK weren't written to fill holes in the software available under the GPL...GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif...These are purely selfish reasons. That is probably why the projects...eventually succeeded. I find it much more difficult to work on something for selfless reasons."
Perlis - "I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn."
otoh the people I deeply detest in software (too numerous to name) are generally these do-gooder types who write software to save the world & provide social service, employment to the masses, add "value" insert-marketing-speak-here etc...
I'm ok with the hypocrisy in pretending to care about software as a social service because I need to put food on the table like any other programmer on the market, but deep inside, I write code only for myself. I think a big fraction of developers are like that. There's no harm in saying it out loud.
I think software is human expression. It can be a social good or a business driver. But it does not have to be. It can have no users, no IO or never run on a computer and still encode deep meaning.
Does it need to be social to be useful? That is a value system.
Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.
you can replace the word "software" with basically any other professional work and that is still the same. I don't know what you can learn from the fact that it's a social service.
Probably something to do with the computer not caring about that. If you constantly divide your time between someone that’s 100% logical, and someone that generally isn’t, you’re bound to get confused.
Gonna expand on this just a bit. Software isn't a product or a service. It's a tool. No end user cares what your stack looks like, they just want to click a button that solves their problem.
Nothing between "click button" and "problem solved" is your user's problem, they're all yours.
Very few recent programs i've seen were socially useful. Some might find comedy in this but the app my current gig uses:
- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)
- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled
- secretaries go faster using fucking paper and filling everything by hand
- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on
> Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...
That's probably because many devs were socially isolated when growing up. (How do you think they got so much time spent tinkering with computers?)
Also, it is generally hard to imagine yourself in other's shoes. Example: imagine trying to use your UI but with a 60-year old vision instead of that of a 20-yo. Example: imagine having no formal address or no citizenship (stateless).
I reached quite the opposite conclusion: the purpose of software is to make a computer do work. Then again, I purposely refrain from writing end-user software and focus on backend automation. It is a deliberate choice.
> “if they ask about time off in the first interview then they are never going to be there!”
The fact that this attitude is common scares me when I'm doing interviews.
Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it?
The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days PTO per year, but trying to actually use more than a single day at a time was always met with denials, and even if you did take a Friday off, you were expected to work 10 hours/day the other 4 days of that week to make up for it.
So yeah, when I'm interviewing, I want to know how much time people are taking off, but I don't want the interviewer to think I'm lazy and will be trying to avoid work as much as possible.
Your quote of the article made me think I was going to hate the advice, but then I realized you quoted it out of context, here's the full quote:
> People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates
As I once told a boss who tried to cancel my already approved vacation in a former job/company, you can't stop me from going. You can only stop me from coming back. Let me know which you prefer. (I really needed that vacation and I was done with bullshit.)
This is especially true if the company uses "unlimited"/not-tracked/etc. time. Otherwise, unless you know someone at the place (and even then it can vary by group), you're left with making assumptions about norms that may not be accurate.
Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.
The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job.
So let me give one advice: you are not producing code, you are engineering code. Some will find solutions that the others will not find. Thats where the 10x programmer thing come from. The guy who wrote bittorrent said something like the following: "I've written bittorrent in a way you would never have thought about".
You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas.
0.1x programmers are often lost or afraid, although they may just be unimaginative. The real risk of fear is introducing 0.1x processes. People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
Sometimes this makes sense, sometimes it doesn't. Arguably the reason for the success of SpaceX is that they were willing to fly, crashland, and improve a dozen rockets in the time that a conventional company would spend agonizing over whether to launch at all. On the other hand, nobody wants to be on the same roads as the "move fast and break things" self-driving car.
> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.
I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves?
I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.
"Interviews are almost worthless for telling how good of a team member someone will be"
Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones.
For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually talk to me instead while answering her questions.
My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there.
That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team.
I've been developing software for decades and here's the most important thing I've learned: systems will be around running for far longer than you ever thought possible, even when you allowed for systems being around for far longer than you thought possible!
Keeping that in mind, I'm continually amazed at the number of developers who just love complexity. Don't get me wrong, they all profess to strive for simplicity but their work betrays them. They just love intricate dances carefully coordinated across several components, never minding how anyone 5, 10, 15 or 20 years down the road will ever comprehend this madness or how it will ever be maintained without incurring exorbitant costs.
I religiously adhere to the KISS principle - Keep It Stupid Simple. Once you think it's simple look for ways to make it even more simple. Think about operations failing at the worst time of day possible on the worst possible day of the year - how will you quickly find and resolve the issue? What if it's a new hire who gets the call? I'm just amazed at how developers gloss over this, all while bitching about the "spaghetti code" they inherited. It boggles the mind.
Speaking of iteration, iterating over the most popular replies to this tells me that the points which hit home enough to drive engagement are replies to the effect of:
1) "No, my 37 day interview process is good, actually."
2) "Rails sucks"
3) "Making a thing people would want to use is a bad idea."
4) (two long threads) "The 10x programmer exists, I saw him once at a con."
5) "No one cares what anyone else thinks."
HN really does represent the finest that the largest corporations have to offer. The proof is in the pudding.
There's also a path-dependent local optimisation aspect to HN comment threads. All things equal, threads that are higher up the page during the right time window get more eyeballs and more engagement, which might encourage people to hang their replies off the currently-popular thread. If we reran the "experiment" under essentially the same conditions we might find that a different bunch of responses get the most engagement.
> 13. Your data is the most important part of your system
+1. Most (including me) internalise, if at all, this lesson the hard way through trial and error.
I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data.
I expected Domain Driven Design (DDD) would address this but it doesn't.
I learned a while ago that answering someone who asks you "What is X?" and replying with a phrase similar to the above is probably one of the worst ways to broach the subject. It comes off as questioning the person's intelligence/knowledge.
Instead try to see it as a teachable moment. If it is something you think is cool and/or you are passionate about, you should be excited that you can show your friend/coworker something really cool. ie: "I've never seen Rick and Morty", "You are absolutely going to love that show. I know what you will be binge watching this weekend!"
Anyhow, to put it bluntly, don't be a dick about it.
This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person.
>> People don’t really want innovation... If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
This sounds ridiculous at a glance, but it 100% matches my own experience in pretty much every company and project I've ever worked on.
It applies to everything; jobs, getting funding. Nobody wants to see real innovation and nobody wants to see real talent. If you're too good as a developer and innovate too much, developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
I feel like once you’ve worked on a few projects the desire to “reinvent” the wheel is quickly destroyed. The main thing they never teach in school and you really can’t understand until your doing it is maintenance.
Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
The difference between a senior engineer and a junior engineer to me is that a senior engineer knows how to evolve a system into the system that they want/need it to be. They don't just say "well, looks like we have to throw the whole thing out the window and use this other new shiny/rebuild it from scratch". The desire to reinvent is important to keep throughout your years as long as it is rooted in reason and in the best intentions of the team and company.
Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
One of the things I have noticed lately is that people who change jobs often have completely different perception of the industry as compared to people who don't change that often. Both of the strategies have pros and cons. For instance people who change jobs quite often don't seem to care alot about the business per say they seem to emphasis on the technology more as compared to people who stick to one org. However, people who have changed job quite often, seem to have seen broad variety to problem sets and always bring fresh new pair of eyes to existing business. People who stick to the same org, do tend to become very conservative but it often good for the business as people not quitting brings lot of stability. Again, it really depends on situation, person to person. In general this is my observation.
Yes, yes and yes. Many times we lose sight of the fact our job is to support the business (money-making) functions of the company. The software itself isn't the end-all-be-all point of what the organization does unless you write open source software all day long and survive off donations. My gut tells me that most departments are like this and sees themselves as the core of the company but I think software engineers think of themselves more highly than most (and more highly than they should). A bit of humility would really help - myself included more than most probably.
I agree with a lot of what he says... A few points are a little off IMHO but I've only been doing this for a few more years than this gentleman. Perhaps I'll feel differently in a few more. :)
In my 22+ years of work as an Engineer/Architect, I've found that:
1. Software development skill means nothing if the power goes out, always cultivate other skills and passions, those passions will drive you to develop more meaningful, functional, and well informed tools.
2. My resume never parses correctly on the job application, no matter how big the company is, and I'll always have to retype it over again.
3. The level of functionality on each company's web site job application tool tells you everything you need to know about the development quality and talent within each company.
> No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things…
I had a great interview with one of the FAANG companies. The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. Still, I did more than average to get "pass" from them. But HR dropped me because she didn't like the answer to "what's your weakness?" question along the lines of - "I focus too much on job at hand to an extent that I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
> "The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer."
I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it.
Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.
> The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
The only thing about the 10x programmer saying that's a myth, is the assumption that it's a quality inherent to the person. You can absolutely accomplish the same level of impact in a week that might take a competent respectable colleague a year, and you don't have to be a genius to do it.
You just have to have a good idea at the right moment. It doesn't even have to be a constant thing. In my career, sometimes I'm just a normal programmer and sometimes I do some bona fide 10x work. A lot the times the 10x work I get the most kudos for will be some absurdly simple low-effort yet impactful thing, like sending pull requests to projects that change a single line of code to bump up a version number in an xml file that has 0days. But because the idea is so simple and almost silly, I can do it a few hundred times and have more impact. Then I can take into consideration that many of these projects I'm fixing are libraries or frameworks, so I'm not only rescuing the project but rescuing their users too.
That kind of transitive impact is what makes 10x possible. Programming isn't like a 19th century assembly line where labor had a very static measurable and manageable impact. Our culture is still catching up in fully understanding and internalizing the enabling impact that computers make possible.
The main thing I’ve learned is there is a glass ceiling of pay as
a SWE and although it seems to pay well, once you have a family to support its pretty much working class. Trying to make money in side hustle is futile for most (You are the commodity compliment to FAANG etc.). Investments are the way to go to increase comfort of living.
Why all the money focus and not about craft and blah blah? Because you are a worker for a business. You will unlikely get to build your magnum opus at work and probably won’t have the energy to do that at the weekend (for most of us). So programming as a job is heavily about earning a living. Work hard, do a great job. If you are 10x then what are
you doing working for someone else anyway? Are they paying you 1M a year?
Anyone who denies the existence of the 10x programmer has either simply not encountered one, or is blinded by their own ego. In my 20 years in industry, I can think of maybe 10 engineers I've directly worked with who were an order of magnitude above all their peers in terms of both code volume AND quality.
These are people who will implement a feature with clean code, well commented, well thought-out and meeting the exact need, correctly structured, in the time that the entire rest of the engineering team would still be scratching their head and debating what to do. One guy years ago who refactored the entire backend at a startup in 2 days, then asked "OK, what can I work on now?" Another guy who wrote an IPC system we needed, which I'd expected would take us 6 weeks, and he did it over the weekend (and it worked perfectly). Another who debugged and patched a critical infrastructure problem in a very complex system, in about 2 days... and would do this time and again, just cranking out features and fixes, week after week.
* "Oh, but their code must have been rushed!" It was fast but not rushed. Some of the best code I've seen.
* "Oh, but they didn't consider user requirements." They did.
* "Oh, they must have been insufferable to work with!" For the most part, super friendly and great teammates.
And so on.
So, sorry if it offends, but some people are just much better developers than everyone else around them (including, possibly yourself). I was much happier after I realized and accepted this fact!
[+] [-] boffinAudio|4 years ago|reply
[+] [-] chaps|4 years ago|reply
Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop.
My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.
[+] [-] SavantIdiot|4 years ago|reply
My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.
His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".
He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.
[+] [-] euske|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.
[+] [-] bbarn|4 years ago|reply
Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.
Software is useless without users.
[+] [-] 535188B17C93743|4 years ago|reply
Edit: Ah, found it.
"Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha
[+] [-] nonima|4 years ago|reply
[+] [-] mooreds|4 years ago|reply
This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.
Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.
[+] [-] dxbydt|4 years ago|reply
I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!"
You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imho its a highly toxic sentiment to think that whatever a programmer does is for other humans. Software as a Social Service...SAAS :)
imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans. Not as a social service. In fact all the people I deeply admire in the software world - Arthur Whitney, Kenneth Iverson, Mattis & Kimball, Perlis, Dijkstra, hell even Linus, are generally characterized as egotistical assholes in the public space who really don't give a flying fuck about social service & humans but care deeply about the software they created for their own selfish reasons.
Mattis is quite explicit about this - "You should understand that the GIMP and GTK weren't written to fill holes in the software available under the GPL...GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif...These are purely selfish reasons. That is probably why the projects...eventually succeeded. I find it much more difficult to work on something for selfless reasons."
Perlis - "I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn."
otoh the people I deeply detest in software (too numerous to name) are generally these do-gooder types who write software to save the world & provide social service, employment to the masses, add "value" insert-marketing-speak-here etc...
I'm ok with the hypocrisy in pretending to care about software as a social service because I need to put food on the table like any other programmer on the market, but deep inside, I write code only for myself. I think a big fraction of developers are like that. There's no harm in saying it out loud.
[1]https://cloudflare-ipfs.com/ipfs/QmQ3C4ooSCmBMuK7mKq4sqVAfGq...
[2]https://www.goodreads.com/quotes/405620-i-think-that-it-s-ex...
[+] [-] vnorilo|4 years ago|reply
Does it need to be social to be useful? That is a value system.
Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.
[+] [-] svilen_dobrev|4 years ago|reply
"software is communication, made by people, for people"
(which is more or less what you say :)
With all the consequences. Most people, on either side, don't get it. Ever.
[+] [-] chii|4 years ago|reply
[+] [-] Aeolun|4 years ago|reply
[+] [-] taneq|4 years ago|reply
Nothing between "click button" and "problem solved" is your user's problem, they're all yours.
[+] [-] agumonkey|4 years ago|reply
- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)
- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled
- secretaries go faster using fucking paper and filling everything by hand
- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on
alas
[+] [-] Waterluvian|4 years ago|reply
I think I get what it means but how do I act on it?
[+] [-] DrBazza|4 years ago|reply
[+] [-] jeffwask|4 years ago|reply
Improvements in my "soft skills" have carried me further than any technical learning.
[+] [-] JohnL4|4 years ago|reply
[+] [-] gjvnq|4 years ago|reply
That's probably because many devs were socially isolated when growing up. (How do you think they got so much time spent tinkering with computers?)
Also, it is generally hard to imagine yourself in other's shoes. Example: imagine trying to use your UI but with a 60-year old vision instead of that of a 20-yo. Example: imagine having no formal address or no citizenship (stateless).
[+] [-] hungryforcodes|4 years ago|reply
[+] [-] zanethomas|4 years ago|reply
[+] [-] xwdv|4 years ago|reply
[+] [-] Annatar|4 years ago|reply
[+] [-] Sohcahtoa82|4 years ago|reply
The fact that this attitude is common scares me when I'm doing interviews.
Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it?
The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days PTO per year, but trying to actually use more than a single day at a time was always met with denials, and even if you did take a Friday off, you were expected to work 10 hours/day the other 4 days of that week to make up for it.
So yeah, when I'm interviewing, I want to know how much time people are taking off, but I don't want the interviewer to think I'm lazy and will be trying to avoid work as much as possible.
[+] [-] didibus|4 years ago|reply
> People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates
[+] [-] aosmond|4 years ago|reply
[+] [-] linuxhansl|4 years ago|reply
I do not need heroes, I need reliable folks who do not burn themselves out.
Or to put it in a cliche... I need people who work to live rather then live to work.
[+] [-] ghaff|4 years ago|reply
Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.
[+] [-] quadcore|4 years ago|reply
You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job.
So let me give one advice: you are not producing code, you are engineering code. Some will find solutions that the others will not find. Thats where the 10x programmer thing come from. The guy who wrote bittorrent said something like the following: "I've written bittorrent in a way you would never have thought about".
You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
[+] [-] pjc50|4 years ago|reply
0.1x programmers are often lost or afraid, although they may just be unimaginative. The real risk of fear is introducing 0.1x processes. People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
Sometimes this makes sense, sometimes it doesn't. Arguably the reason for the success of SpaceX is that they were willing to fly, crashland, and improve a dozen rockets in the time that a conventional company would spend agonizing over whether to launch at all. On the other hand, nobody wants to be on the same roads as the "move fast and break things" self-driving car.
[+] [-] scottious|4 years ago|reply
I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves?
I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.
[+] [-] wccrawford|4 years ago|reply
Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones.
For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually talk to me instead while answering her questions.
My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there.
That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team.
That's what interviews are for.
[+] [-] taylodl|4 years ago|reply
Keeping that in mind, I'm continually amazed at the number of developers who just love complexity. Don't get me wrong, they all profess to strive for simplicity but their work betrays them. They just love intricate dances carefully coordinated across several components, never minding how anyone 5, 10, 15 or 20 years down the road will ever comprehend this madness or how it will ever be maintained without incurring exorbitant costs.
I religiously adhere to the KISS principle - Keep It Stupid Simple. Once you think it's simple look for ways to make it even more simple. Think about operations failing at the worst time of day possible on the worst possible day of the year - how will you quickly find and resolve the issue? What if it's a new hire who gets the call? I'm just amazed at how developers gloss over this, all while bitching about the "spaghetti code" they inherited. It boggles the mind.
[+] [-] RNCTX|4 years ago|reply
1) "No, my 37 day interview process is good, actually."
2) "Rails sucks"
3) "Making a thing people would want to use is a bad idea."
4) (two long threads) "The 10x programmer exists, I saw him once at a con."
5) "No one cares what anyone else thinks."
HN really does represent the finest that the largest corporations have to offer. The proof is in the pudding.
[+] [-] shoo|4 years ago|reply
[+] [-] vishnugupta|4 years ago|reply
+1. Most (including me) internalise, if at all, this lesson the hard way through trial and error.
I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data.
I expected Domain Driven Design (DDD) would address this but it doesn't.
[+] [-] mrpotato|4 years ago|reply
> “How can you not know what BGP is?”
I learned a while ago that answering someone who asks you "What is X?" and replying with a phrase similar to the above is probably one of the worst ways to broach the subject. It comes off as questioning the person's intelligence/knowledge.
Instead try to see it as a teachable moment. If it is something you think is cool and/or you are passionate about, you should be excited that you can show your friend/coworker something really cool. ie: "I've never seen Rick and Morty", "You are absolutely going to love that show. I know what you will be binge watching this weekend!"
Anyhow, to put it bluntly, don't be a dick about it.
[+] [-] cryptica|4 years ago|reply
>> Nobody asks “why” enough
This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person.
>> People don’t really want innovation... If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
This sounds ridiculous at a glance, but it 100% matches my own experience in pretty much every company and project I've ever worked on.
It applies to everything; jobs, getting funding. Nobody wants to see real innovation and nobody wants to see real talent. If you're too good as a developer and innovate too much, developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
[+] [-] sporedro|4 years ago|reply
Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
[+] [-] jb3689|4 years ago|reply
Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
[+] [-] debarshri|4 years ago|reply
[+] [-] StatsAreFun|4 years ago|reply
Yes, yes and yes. Many times we lose sight of the fact our job is to support the business (money-making) functions of the company. The software itself isn't the end-all-be-all point of what the organization does unless you write open source software all day long and survive off donations. My gut tells me that most departments are like this and sees themselves as the core of the company but I think software engineers think of themselves more highly than most (and more highly than they should). A bit of humility would really help - myself included more than most probably.
I agree with a lot of what he says... A few points are a little off IMHO but I've only been doing this for a few more years than this gentleman. Perhaps I'll feel differently in a few more. :)
[+] [-] winternett|4 years ago|reply
1. Software development skill means nothing if the power goes out, always cultivate other skills and passions, those passions will drive you to develop more meaningful, functional, and well informed tools.
2. My resume never parses correctly on the job application, no matter how big the company is, and I'll always have to retype it over again.
3. The level of functionality on each company's web site job application tool tells you everything you need to know about the development quality and talent within each company.
[+] [-] chown|4 years ago|reply
I had a great interview with one of the FAANG companies. The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. Still, I did more than average to get "pass" from them. But HR dropped me because she didn't like the answer to "what's your weakness?" question along the lines of - "I focus too much on job at hand to an extent that I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
[+] [-] elihu|4 years ago|reply
I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it.
Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.
[+] [-] jart|4 years ago|reply
The only thing about the 10x programmer saying that's a myth, is the assumption that it's a quality inherent to the person. You can absolutely accomplish the same level of impact in a week that might take a competent respectable colleague a year, and you don't have to be a genius to do it.
You just have to have a good idea at the right moment. It doesn't even have to be a constant thing. In my career, sometimes I'm just a normal programmer and sometimes I do some bona fide 10x work. A lot the times the 10x work I get the most kudos for will be some absurdly simple low-effort yet impactful thing, like sending pull requests to projects that change a single line of code to bump up a version number in an xml file that has 0days. But because the idea is so simple and almost silly, I can do it a few hundred times and have more impact. Then I can take into consideration that many of these projects I'm fixing are libraries or frameworks, so I'm not only rescuing the project but rescuing their users too.
That kind of transitive impact is what makes 10x possible. Programming isn't like a 19th century assembly line where labor had a very static measurable and manageable impact. Our culture is still catching up in fully understanding and internalizing the enabling impact that computers make possible.
[+] [-] quickthrower2|4 years ago|reply
Why all the money focus and not about craft and blah blah? Because you are a worker for a business. You will unlikely get to build your magnum opus at work and probably won’t have the energy to do that at the weekend (for most of us). So programming as a job is heavily about earning a living. Work hard, do a great job. If you are 10x then what are you doing working for someone else anyway? Are they paying you 1M a year?
[+] [-] khazhoux|4 years ago|reply
These are people who will implement a feature with clean code, well commented, well thought-out and meeting the exact need, correctly structured, in the time that the entire rest of the engineering team would still be scratching their head and debating what to do. One guy years ago who refactored the entire backend at a startup in 2 days, then asked "OK, what can I work on now?" Another guy who wrote an IPC system we needed, which I'd expected would take us 6 weeks, and he did it over the weekend (and it worked perfectly). Another who debugged and patched a critical infrastructure problem in a very complex system, in about 2 days... and would do this time and again, just cranking out features and fixes, week after week.
* "Oh, but their code must have been rushed!" It was fast but not rushed. Some of the best code I've seen.
* "Oh, but they didn't consider user requirements." They did.
* "Oh, they must have been insufferable to work with!" For the most part, super friendly and great teammates.
And so on.
So, sorry if it offends, but some people are just much better developers than everyone else around them (including, possibly yourself). I was much happier after I realized and accepted this fact!