Hacker News Reader

Comment by mikepurvis | Hacker News Reader

I agree with the conversation starter part, but I think there's still something to be said for seeing how someone's code looks when they're writing it not-for-production.

Like does that just mean overly long functions? Lazy symbol naming? Linter violations? Lack of tests? Those might all be reasonable through the "not prod" lens, but there's other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used, or using obviously non-idiomatic structures like an indexed loop in Python.

None of this should be a deal breaker, but if you're seeing stuff that's obviously like "I would be annoyed to be reviewing this code" then it's worth talking about.

View on HN

> other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used

One of the reasons why I enjoy programming as a hobby and avoid it as a profession is the pleasure of reinventing the wheel. For example: I learnt how to use git and am learning how to read datasheets is by taking simple Arduino programs then refining it until most of the abstractions are removed. Likewise, it can be fun to implement my own data structures and algorithms. Contrast that to simply using libraries. It's mostly an exercise of reading documentation and hoping that a tiny subset of what's learnt is transferable to other libraries.

Okay, understandable. I do feel there's a pretty big difference between doing something a bit different for the sake of preference or taste or experimentation vs doing it because you just didn't know, or you don't have the familiarity with the ecosystem to even know what's out there. And this difference is usually fairly evident in the code itself.

If nothing else, again, it's an opportunity for a conversation— the person might have a great war story about how they deep-dived on library X after finding it lacking, or tried to submit a PR that was shot down. Or even if they had no idea, it's an opportunity for them to demonstrate teachability, like "oh that looks nifty, yes I can definitely see how that would make this whole section redundant and the rest easier to read."

This smells of career stage myopia.

As an early career developer, your team wants you to write useful code with few errors and that works best when you can rely on established libraries.

But as your career progresses, your value comes from understanding how those libraries work and from being capable of writing new libraries that support and stabilize the early career developers coming up behind you.

And the only way to go from the first group to the second is from getting your hands dirty. Writing personal and hobby projects that “reinvent the wheel” is one of the best ways to do that.

One of the nice things about open source, and modern development tools, is the ability to easily go beyond the documentation to explore the library code itself. While I wouldn't consider that as a substitute for implementing your own, it is another means of figuring out how a library works and can be seen as more results oriented. Yet it is nowhere near as interesting, in my opinion.

Imagine you’re hiring a structural engineer to work as part of a highly skilled team on a skyscraper project. They previously worked on a bunch of major building projects around the world.

What you’re going to do, though, is ask them to let you have a look round the treehouse they built on weekends in their backyard.

After all, the choices of materials and techniques they use there in that ‘not for production’ context probably tell you a lot about how they approach their work, right?

Sure. But not because you're expecting the treehouse to be at the caliber of a major building project. Rather because it's an opportunity to witness:

- What their work looks like when they're solely in charge of it and it's not a massive, long-lived team effort.

- Obvious flaws that shouldn't be acceptable to anyone. Like, loose boards, nails sticking out, a fence that's not supported and may collapse if a kid leans on it wrong.

Neither of these things are the entirety of the evaluation, but IMO they're a relevant signal to use in combination with talking through past professional projects, particularly if the professional projects aren't visible or known to the interviewer.

The difference with software is that you are not allowed to look at the skyscraper, because it is the intellectual property of another company.

So you're saying that, if skyscraper engineering designs were considered confidential and proprietary, preventing you from being able to directly investigate them, it would be perfectly reasonable to fall back to evaluating structural engineers for skyscraper projects on the basis of how well they put together treehouses?

Nah, you could just have them come and build something at your office while you watch them, and ask them leading questions when they get stuck.

I thought that the commenters who were sheepish about including their GH repo were being unreasonable until I read this comment. I could not disagree more about the purposes of side projects. In fact, if "reinventing the wheel where a well known library could have been used" is a deal breaker for people _in a side project_, I must be one of the least hire-able people on earth.

I love breaking things down to understand them. Rewriting them (sometimes better!) to get a feel for what is involved. I think it makes me a better programmer. It saddens me to hear that this is an undesirable quality in seeking engineering candidates, for some.

I like re-implementing things too! But usually there's a pretty clear difference between "I'm doing this deliberately differently from established-solution X for reasons Y and Z" vs "I'm doing an unrelated task and am using urllib because I'm blindly copying in SO solutions from ten years ago and have never heard of Requests." This kind of thing is the fizzbuzz of ecosystem-awareness.

For an example from my own code— I was learning Rust via AoC a few years ago, and I deliberately chose to do some of the challenges with natural language inputs using Pest rather than just dumb regexes [1]. The regex solution would have almost certainly been shorter and quicker for this limited task, but I would have no trouble justifying this design choice to an interviewer as having been an intentional learning experience.

[1]: https://github.com/mikepurvis/advent-of-code/blob/master/202...

The thing is, reasons Y and Z for me very often are "because I want to". I don't even really want to fluff it up and call it something nauseating like "professional growth". I just followed my curiosity. My personal projects are a safe space from stiff professional judgement (or at least were).

You're my favourite kind of employee/colleague. Someone who knows something about what they're doing because they took it apart and put it back together.

Thank you fartcannon. May we hack into the long night

> like the person reinventing the wheel where a well known library could have been used

This is a particularly shitty signal to my mind. Half the reason to experiment with writing software outside of work is to reinvent the wheel and see what shakes out - you'll almost never have the opportunity to do that at work, and if nobody ever does that, we never discover better ways of developing software.

I think it's a difference between: "reinventing the wheel because I didn't know better", and "reinventing the wheel because I feel like trying to make it better". There's usually a distinct difference in how the code shakes out between the two.

Overly long function names and lazy symbols, fair enough. Linter violations, Im not sure sure, standardised code style is most important when working in a team, working on your own it doesnt really matter as much, but fine. Lack of tests, theres no way I'm writing tests for a fun weekend project not meant for production. I'm not even sure I'd write tests for any project not meant for production or anyone elses uses (obviously what production is in that context differs, if your writing a library for dev tooling, their dev is your production).

As for "reinventing the wheel", this overuse and overdependence on hundreds of libraries is how we as an industry keep running into the same old issues, so I'd quite happily reinvent the wheel for production. I'm not adverse to libraries, but they shouldnt be approached as a first resort.

I'm just glad I don't have my github on my CV

> I'm not even sure I'd write tests for any project not meant for production or anyone else's use

See that's interesting— I'm far from a testing-absolutist, and I agree with the basic premise here that there's no point having an elaborate "testing" strategy for a one-off script, stuff that isn't very branchy, etc.

However, there's also some stuff that I basically always write a trivial unit test for, assuming the language is set up to allow me to do so cheaply. Obvious examples of this include any kind of string processing, parsing, or regex-type logic— I'm just like, this looks fragile, and I'd like to know for me that it does what I think it does and I'm not going to be tripped up later by some subtle bug that boiled down to an edge case in this particular piece of trivially-isolated and testable logic.

Yeh, that makes sense, I just doubt I'd even think to add unit tests for a quick and done project. Even if it did cross my mind, I think I'd just add exceptions and print statements. Its dirty, but its also very quick and painless.

Then again, I haven't used unit tests much at all in any language other than Python (maybe a few others, but not for some time certainly), maybe other languages make it much easier.

> there's other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used

I wouldn't call not using a well known library "reinventing the wheel". The wheel in that expression is a concept, not a implementation. A library is an implementation of a concept. Writing yourself code instead of using a library is a great way to learn about what that library does and the tradeoffs it makes.

When I think about "reinventing the wheel" as something negative, I think about something like "Medical researcher discovers integration, gets 75 citations": https://fliptomato.wordpress.com/2007/03/19/medical-research....

What if I wanted to reinvent the wheel to increase my knowledge?

Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.

And what if I’m not tracking that in such detail or even thinking about viewing it like that because it’s a side project?

My repos are hidden specifically because I do them for fun. I’d make them public if tinkering were an understood thing but its not.

> If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him.

Better to have a clear separation between work and play.

> And what if I’m not tracking that in such detail or even thinking about viewing it like that because it’s a side project?

Make it private like you are doing?

If you don't want someone to perceive something about you, then don't make it public. If you do make it public and add it to a resume then don't be surprised if the person who manages programmers is interested in possibly looking at the programming that person has done.

I proposed that you can tinker in public if you make sure your tinkering won't be confused for your magnum opus. You dismissed that because a one sentence readme isn't needed on a public side project.

You're not the target demographic. It was shared with other programmers, not submitted for your judgement.

> If you do make it public and add it to a resume

I didn’t say anything about adding a link to a resume. This thread has hints of people thinking “I’ll just look up their GitHub if they don’t include it” and other threads make that explicit.

> You dismissed that because a one sentence readme isn't needed on a public side project.

I don’t think that’s what I said. I was saying that tracking all the things one might be judged for is unreasonable, not that having a readme is unreasonable.

https://news.ycombinator.com/newsguidelines.html

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

> Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.

Your comment is a great reason for me not to share my Github profile.

I'm not going to treat my Github project defensively. The notion that most people need to worry about what they put in their README because some interviewer is going to look at it - it's just so much better not to let them see your Github profile.

The irony with this article is that it's proposing a solution to a problem - yet that solution is as problematic. A resume is a poor indicator of one's skills, as is their Github profile.

Sure, if you don't want people to look at your code, don't make it public?

I'd argue with you that a GitHub profile could be a useful signal, but it's not a given.

As a hiring manager:

- If they don't have a GH profile, I won't ding them.

- If they add it to the resume, and it's a scrap yard, I won't ding them.

- If they add it to the resume, and it's well maintained, I will ask questions about it.

- If they add it to the resume, and it's clearly deception, I will have a negative perception.

I feel like most hiring managers take this approach.

Sharing is caring. It's not an invitation for unsolicited judgement.

The message is "I code in ny spare time" not "this is representative of my professional work"

Why should I have to defend the imperfections of what I do for fun? I wasn't getting paid to make it good.

It's a personal project. I do it for fun. I didn't write tests because it wasn't fun. I cut corners to get to the fun part faster. I made breaking changes because the one single user accepted them.

> other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used

OTOH, reinventing the wheel as a hobby and to deepen understanding makes perfect sense.

Reply on news.ycombinator.com