How to be a wizard programmer | Hacker News Reader

How to be a wizard programmer

twitter.com

113 pointsknoxa251162 comments

I'm going to be the token buzz-kill senior dev:

If you run into problems none of the senior devs have experience in and have no answers for, my first concern is that you're massively over complicating something we've solved in a simpler and less risk-exposed way. My second concern is that you're intentionally reinventing the wheel in a way that is massively over complicating something we've solved in a simpler and less risk-exposed way just for your own interest.

Unless your question is: "How does this legacy system work? Why can't we make it do what we want to make it do?" I built my career on this :-) Give me your worst code! The best thing about this is that nobody gives a crap what you do with that stuff as long as you don't break it. Say goodbye to the endless conversations of how to indent your code.

OP is proposing you solve the problem if no one else has a solution. You are proposing to solve the problem by simplifying. I don't think these need to be mutually exclusive pieces of advice.

I think what he's trying to say is that if you find yourself with problems that none of the senior people have had to solve before, it's very likely that you are modeling the target system as the wrong problem. As a strawman example, "how can i make a new class inherit from multiple classes" is attacking the wrong problem (multiple inheritance), but a junior person might not be aware that it's the wrong problem.

Or the question is "can we solve this better with the actor model", which is what I asked my team last week.

None of us has any experience with the actor model, but rather than dismissing the question, we're investigating.

If the senior people have never had to solve the problem before, how can they know if it's a valid problem?

Part of being a senior dev is realizing that novel problems are extremely rare, and when confronted with one first investigating what's actually needing to be solved before diving into designing a novel (and possibly complex) solution.

This is how dinosaurs are born.

"No experience in and no answers for" implies a gap in your knowledge, not a bad question.

I once wrote some code that unintentionally smashed the interpreter's error-tracking data structure at compile-time. If you had even the slightest error in that module, like a misspelled variable name or type error or unknown function, you'd just get "Unknown error".

I never bothered to fix it, so I believe it's still in production. You better hope you're not assigned to maintain that module.

The one bug at my last job that gave me trouble was one where somebody deep in the stack called the C close() on a filehandle managed by the interpreter. The bug report was "My reports are showing up empty when I run them". The language interpreter kept track of its filehandles separately and wasn't informed about the close, and this led to an off-by-one error when you later went to write to a language-managed filehandle. I noticed stat'ing the filehandle gave a different inode than the temporary file it was supposed to be opening. I moved over to an ext4 filesystem so I could use the debugfs command to look up the inode, but the error only showed up on the same xfs filesystem. A brute-force search of the filesystem turned out that the report was being written to one of my Perl source files, which was opened read-only and so the writes were being rejected. The commit that introduced the error caused it by adding an include, which shuffled the order that filehandles get allocated, which exposed the off-by-1 error that had been around for 10 years which usually didn't cause any trouble.

Took me a solid week to track that one down.

Until the more senior member quits because they are wasting the vast majority of their time answering questions that could have been answered by just trying for more than 30seconds after hitting an obstacle...

You're demonstrating why people become afraid to ask questions, and stop doing so even when they should.

I'd much rather have someone ask when they get stuck, or even if they're kinda stuck. If someone happens to ask me a question that's easily found via poking around a bit more, I'll show them how they could have found the answer, and then they'll have learned two things: the thing they wanted to know and a new pattern for solving problems.

As a result, I rapidly find myself surrounded by people who ask smarter and smarter questions, and who can solve harder and harder problems. And I love that result.

Somewhat inexperienced team leader here. IMO, working on improving the team's knowledge as a whole is so much more rewarding than working on your own knowledge and snapping at people who want you to share it.

The style I favor when the junior devs ask me questions is to ask questions right back at them, kind of like in a Socratic dialogue. This makes them reluctant to come to me for easy answers and think more about the problem first.

In the end I get a team of people with steadily improving skills to whom I can delegate ever more complex tasks.

Thanks for this

Ironically enough, it's always been the same people who snap about being bothered with questions, who are the first to go running for help when they are confused by something outside their domain of expertise.

That's been my experience at least. My very first job was especially bad. There was an entire culture built up where tech leads and senior engineers would never answer chats/emails sent by junior engineers. If you really needed a clarification, you had to hunt them down in their cube, where if you're lucky, they would answer your question without any condescension. At my very first performance review, I was even dinged for "asking too many questions."

At the time, I thought there was something wrong with me. Looking back, the reason why I had to ask so many questions was because there was zero documentation, the code base was horrific, and we were using stone age tooling. My only regret is that I hadn't left even earlier than I did.

I've had a similar experience where I joined a new company, worked for four weeks, had a performance review, and was told that I had lost the confidence of my coworkers and if I don't improve my productivity, I'd have to be let go in a month. I quit immediately.

I was contributing from day one. I had introduced unit tests to their code. I implemented a Stripe integration for subscriptions. I added new features. After receiving one of my questions, the senior dev would take a long hard look at me, thinking of the dickest thing to say, then he'd say it. The responses were always condescending and rarely helpful. I became afraid to interact with him.

No matter what I did, I did it the wrong way. He didn't offer solutions, just criticism. When I mentioned that working with this guy was incredibly difficult, my employer said that he understands, but this individual is so good at what he does, it's just something they'll have to deal with. Life is too short to deal with these toxic individuals.

As long as they dont keep asking the same question over again... Now that does get annoying.

My experience is that people not asking questions when they should is far less common than not taking the time to think when they should. I've found most people's response to a challenging problem is to ask someone for an answer rather than take the time to use their brain and solve it themselves. This might frequently be the fastest way to solve the problem, but there is tremendous value in learning to apply yourself and tackle challenges; it also results in a greater diversity of solutions.

Worse is when they tell you your code doesn't work. Spend half an hour "debugging" it only to find its their code that is the problem.

>then they'll have learned two things

I used to do that. What would happen is people learn they _dont need_ to poke, because this sucker has all the answers on a platter, so why bother.

What I would prefer, is somebody who tries to figure it out themselves, even if it takes more time ... just maybe I don't have the answers and would like somebody to give me information for a change rather than just take take take ...

I think there is a balance somewhere.

I once talked to a teacher about that problem. He told me that most of the time it's hard to tell what is the right balance between giving the answer or pointing towards the answer, if you do it too early you kill the opportunity for some one to improve their knowledge acquisition process or simply their cognitive ability to reason about a complex subject(or more often, a subject they are not familiar with).

However, if you intervene too late you can make a student go on his way for too looking for an answer that's too complex(for the time frame given to solve the problem) or that's in wrong direction(like trying to optimize a small part of a project that's not all that important) or even more commonly, the student can remain oblivious regarding a shortcut that can make his life a lot easier.

I always think of those problems when dealing with a new intern and I'm still unsure on how to deal with it, but one thing I'm starting to understand is that different people have different personalities(that are constantly changing), so they require different approaches at different moments

Indeed there is, and I'm just providing a counterbalancing opinion.

As the man says "there is no silver bullet".

Parade: always ask "what have you tried?" first. Then it's acceptable to just give just a direction (the simplest of which is "try googling for it") and to tell them to come back when they've tried if the problem persists.

I found this the most useful thing about StackOverflow - it taught me how to both ask and answer questions more effectively.

Bad:

> "I have an error. What do I do?"

Better:

> "I have this error: {BLAH}. What do I do?"

Best:

> "I'm trying to do X. I have this error: {BLAH}. I read the documentation and tried doing Y, but it didn't fix it. How I can I do X?"

Similarly, I try to avoid giving answers that are just "change this line to x". You're just a code-fixing machine into which you pump questions and answers are spat out. Nobody learns anything that way, and you're going to answer the same question over and over again, and get annoyed.

It happened to me as well, and now I think that half of the times I am asking something on StackOverflow, I end up finding the answer myself while writing the question.

See also, rubber duck problem solving: https://blog.codinghorror.com/rubber-duck-problem-solving/

I really enjoy environments in which everyone feels safe asking dumb questions; if I have a question and there's someone able to answer, I ask.

I like answering questions, especially when this leads to someone's growth; it's a satisfaction to me when the junior goes from newbie questions to more and more advanced ones.

But, even if I disliked answering questions, I'd still very much prefer answering questions than having to clean after a junior that didn't dare to ask a question.

More likely in my experience, the senior member feels valuable for being able to answer questions and help others.

Not after twentieth question of similar construction and similarly easy to be answered by the one who asked if he actually read the friggin' docs.

Seniors like to help learn, not to be used as a walking manual.

I think you're right when it comes to basic questions (like "how to do XXX in rails"). However, in my practice, 90% of the obstacles are not concerned with how to do something in the framework/language of choice, but rather "how do we do XXX in our code?" (state machines, search, billing, reporting, etc). These questions can be answered by digging into code and understanding the logic, however, it's better if someone senior explains how and why they do things the way they do, clarifies rationale.

When it's the first hit on Google you start feeling as though you are doing other peoples' work for them. Luckily I now have a fantastic manager: she aggressively defends the time of all her team members.

Being a wizard developer also requires a wizard manager that the developers can trust completely.

While I do sometimes have people ask questions that I can easily find the answer to, I rarely have people ask questions that they can easily find the answer to. Sometimes, it's the first search result for a term they didn't happen to know, for instance, and mentioning that term helps them. (Also consider the concepts of "inferential distance" and "illusion of transparency".)

And even the concept of "search for the error message" is a pattern someone needs to learn, once. Ideally it's one they'd learn very early on when learning. But I've found that very few people talk about or provide guidance in the processes of learning themselves. Which is why I'm glad that people write down advice like the page tweeted here.

> it's the first search result for a term they didn't happen to know

> even the concept of "search for the error message" is a pattern someone needs to learn

I suppose if we're talking about a graduate or intern this is okay, but when you have somebody that supposedly has a few years experience this is just infuriating.

There is also the point that you shouldn't be getting a graduate/intern to be doing work they haven't the capability to google the terms of ...

>but when you have somebody that supposedly has a few years experience this is just infuriating.

You know how sometimes programmers on Hacker news talk about toxic team mates who are hard to work with and bog the whole team down through arrogance?

Becoming furious when someone asks you a question and truly wishing they'd waste half a day deriving it from first principals themselves rather than just asking you and having an answer in 30 seconds makes you one of those toxic team mates.

Modern software development is a team game. The average speed of the team is what matters, not your personal speed.

And it's great to have a management chain that recognizes this: it's hard to find people who specifically go out of their way to build up a team around them, so recognize and reward those people highly.

Given the choice, I don't want a "10x" programmer who works alone or only wants to work with other "10x" programmers. I want a 2x programmer who turns everyone around them into a 2x programmer while becoming a 4x programmer, and who then turns all those 2x programmers into 4x programmers while becoming an 8x programmer, and whose newly minted 2x programmers turn everyone around them into 2x programmers while becoming 4x programmers.

Sir, I have worked with many a toxic team-mate who did nothing but wander around the office, making noise, and getting other people to do their work. Because they didn't do their work themselves they didn't have ownership of it, and it simply "didn't work" and when something inevitably went wrong with it others had to sort it out because it's the team that matters, not blaming an individual. This slowed the overall velocity of the team, despite our best intentions in giving these guys a dig out. I really see no need to smear me for having a countering opinion.

I have had co-workers claim that they think someone has gone in and altered their code overnight, as it was working yesterday (I ended up debugging the problem for her and fixing it in the end).

That sort of attitude gets seriously wearing.

As a senior level engineer myself, I always say, "I want to do my part, and part of that is to help you do yours better."

As long as someone isn't being willfully ignorant, I'm more than happy to help them, as them doing their job better helps me do mine better.

As someone senior myself, I really don't mind the easy to answer, quick questions. It's when people dump real time sinks onto me that will cause me irritation, as I then need to manage my time and realign all my own pending tasks.

Assuming your company values an aptitude for learning when it makes a hire (at all developer levels), then you should be in good shape and this won't ever be a problem.

Note also that there's a subtle difference between senior devs and experienced jerks.

The correct answer isn't always the end result. Instead, make your answer where you sit with them on the "try" for that thirty seconds.

Obviously, you could have someone that will always ask and not try. My gut, though, is that spending that thirty seconds just a couple of times will save you hours of future work.

Never happened in my company.

It's amazing how encountering handwritten text, a scarce thing these days, somehow grabs your attention immediately.

How to be a wizard programmer:

1. Write Code

2. Read Code

3. Learn how to find out things for yourself

4. Find new ways of doing things and contribute to the team

5. Try to give more than you take

Something that made my coding skills jump: Attempting to reverse-engineer a extremely large, and known to be well coded by wizards C++-based game.

I ended having to learn details on how C++ work (how vtables work? why?, etc...), what some common stuff on the code was (reference-based smart pointers, locks of various kinds, thread-related stuff, alignment-based custom fast allocators, STLPort stuff, etc...), reading papers about why some things were done that way (yep, the game I choose has lots of papers and talks about its coding!), and so on.

In the end, I couldn't find any of the things I wanted to find, and couldn't convince the game IP owner to let me patch some bugs I found (that are actually killing the game review ratings on Steam), but I don't regret it one bit, I felt like I learned in the 3 months I fiddled with that, the same amount of information I needed to learn in 2 or 3 years of coding my own projects.

I'm curious what would work better. Reading and working for open-source projects or reverse engineering like you did. I noticed that my coding skills became better when I did a reverse engineering class, mainly because I needed to debug a lot more than normal.

Another great learning experience is taking a code base written in one language and porting it to another. I keep poking around at the old IdTech code and reimplementing parts of it. About the most productive thing I've managed is an extractor for the Wolfenstein 3D graphics files, but I've had fun and reviewed a lot of my C knowledge, along with some dusty corners of the language I was porting into that I don't use much.

Any blog post on how you did it and what tools you have used?

Of course not.

Lots of the stuff involved are borderline illegal, or in some countries completely illegal, this is why also I don't say the name of the game on my post.

I don't want that to come haunt me later.

Tip #1 seems to be a brilliant way to get shouted at @ Stack Overflow...

Is wizard better than ninja or rockstar?

(Am I the only one that gets put of by job ads asking for nonsense titles like these?)

Companies write job adverts using that language for one of two reasons - either because they think it's flattering and want to get developers who will fit in to a culture where they already use that language, or because they don't understand the language and think that will attract the best people.

The first type of company is a great place to learn new things if you're quite junior. The second is a good place to demonstrate your ability to hack solutions together fast if you're mid-level.

If you're more senior then you should probably avoid all of those sorts of companies because neither will want to do things in anything resembling a sane way.

Once upon a time it used to have a sensible meaning[0].

Nowadays I'm more interested in people that are effectively building stuff and just s/[:buzzwords:]//g.

[0]: http://www.catb.org/jargon/html/W/wizard.html

I feel the same way. I'm looking for a job, not a cult to join.

I would rather be an actual wizard than an actual ninja or rockstar.

In job ads rockstar is definitely the most annoying/lame one.

But, yes, wizard is better.

I think the hierarchy goes pirate, ninja, wizard, rockstar and guru.

Where is "commando" in there?

For many years now "commando" is no longer a title but rather a state; a state where one lacks under garments, and of course a lack of support. ;-)

Commandos are deprecated, like cowboys :)

I steer clear of superfluous titles like these. I think these titles mainly exist to cater to the demographic of people who seek some additional validation from their job title... Nobody likes someone with an overinflated ego, let alone a programmer with a big head.

Is there anyone who is not put off by those titles?

Reply on news.ycombinator.com