8 ms·

This was also my reaction, the way I write code when I have a 20 minutes of free time after work is really different from the way I write code for production. T

by tym0 4y ago

This was also my reaction, the way I write code when I have a 20 minutes of free time after work is really different from the way I write code for production. The author is lying to themselves if they think that most people Github projects are any more representative of the work they'll do once hired than their resume is. I think looking at the Github of applicants is useful as a conversation starter however: "Oh I see you've built X with Y, what was interesting about that? What did you learn?"

mikepurvis 4y ago
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.
- whiddershins 4y ago
  What if I wanted to reinvent the wheel to increase my knowledge?
  - lbotos 4y ago
    Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.
    - reificator 4y ago
      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.
      - lbotos 4y ago
        > 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.
        nicbou 4y ago
        You're not the target demographic. It was shared with other programmers, not submitted for your judgement.
        reificator 4y ago
        > 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 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.
    - BeetleB 4y ago
      > 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.
      - lbotos 4y ago
        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.
        nicbou 4y ago
        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"
    - nicbou 4y ago
      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.
- II2II 4y ago
  > 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.
  - mikepurvis 4y ago
    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."
    - swatcoder 4y ago
      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.
      - 4y ago
- jameshart 4y ago
  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?
  - mikepurvis 4y ago
    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.
  - jimbokun 4y ago
    The difference with software is that you are not allowed to look at the skyscraper, because it is the intellectual property of another company.
    - jameshart 4y ago
      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?
      - jimbokun 4y ago
        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.
- swiftcoder 4y ago
  > 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.
  - chipsa 4y ago
    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.
- cnity 4y ago
  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.
  - mikepurvis 4y ago
    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/2020/day-19/src/main.rs https://github.com/mikepurvis/advent-of-code/blob/master/202...
    - cnity 4y ago
      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).
      - fartcannon 4y ago
        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.
- bodge5000 4y ago
  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
  - mikepurvis 4y ago
    > 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.
    - bodge5000 4y ago
      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.
- Zababa 4y ago
  > 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-researcher-discovers-integration-gets-75-citations/ https://fliptomato.wordpress.com/2007/03/19/medical-research....
- HWR_14 4y ago
  > 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.
shikoba 4y ago
> Github projects are any more representative of the work They are, that's the moment you see how the person code when she/he is responsible. You see the real skills and potentials of that person.
- jameshart 4y ago
  I disagree profoundly with this assertion. On a personal project there is no accountability. The developer didn’t have to understand what someone else wanted and try to figure out how to make it real. They set their own goalposts and had freedom to move them at will. You have no idea what their ambition was. Adam Savage had some interesting insights relevant to this in the context of evaluating model makers and artists for special FX work. While portfolio pieces showing their own concepts or creations might show off heir basic craft skills, it doesn’t show that they can create something to fulfill someone else’s vision - and that is the job. So what you want are portfolio pieces where they have drawn or built something recognizable - a replica or a scale model or portrait or something. Because that shows they can direct their skill to a particular goal. You know what they were trying to go for, and you can tell whether or not they nailed it. Mostly I’m hiring for developers to work in a large team, within a large organization. What they can accomplish when left to their own devices is scarcely relevant to what they will be able to do in that work environment.
  - shikoba 4y ago
    When I see undocumented project that doesn't build, I know that the developer doesn't care about the quality of his work.
- deleted 4y ago
  [deleted]
- xboxnolifes 4y ago
  > They are, that's the moment you see how the person code when she/he is responsible There is no responsibility in small side projects. I write better code during my day job because I know other people will eventually have to interact with it.
mauvehaus 4y ago
I don't even code professionally any more, but when I gin up some code to solve a problem for myself in 20 minutes, I'll definitely try to clean it up before I throw it up on GitHub. I don't get any competitive advantage or economic benefit from my code, so maybe it's different for me, but if somebody finds my stuff and wants to use it, I feel like it's basic courtesy to not hand them something I vomited onto the internet. If you just want an offsite backup for your noodling around, make it a private repo; the contributor limit won't be a problem. If you're putting it out for the world to see, take the time to comment it, put a little polish on it, a decent README, and a license. If nothing else you'll be starting from a place of sanity if you ever have to revisit the code.
- pc86 4y ago
  I disagree but want to explain why. I don't view GitHub as a place to show off your code, or a place to find new code, or whatever. It's where my code is stored. I trust what's on GitHub more than I trust what's on any server, or any laptop, or running on my dev environment right now. As such, the idea of "cleaning it up" before putting it on GitHub seems backward. Code gets committed as soon as it's written, and if it gets cleaned up that history gets saved too. If somebody wants to pull my shitcode down that doesn't even have a readme, that's on them.

by tym0 4y ago

mikepurvis 4y ago

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.

whiddershins 4y ago
What if I wanted to reinvent the wheel to increase my knowledge?
- lbotos 4y ago
  Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.
  - reificator 4y ago
    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.
    - lbotos 4y ago
      > 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.
      - nicbou 4y ago
        You're not the target demographic. It was shared with other programmers, not submitted for your judgement.
      - reificator 4y ago
        > 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 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.
  - BeetleB 4y ago
    > 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.
    - lbotos 4y ago
      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.
      - nicbou 4y ago
        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"
  - nicbou 4y ago
    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.
II2II 4y ago
> 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.
- mikepurvis 4y ago
  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."
  - swatcoder 4y ago
    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.
    - 4y ago
jameshart 4y ago
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?
- mikepurvis 4y ago
  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.
- jimbokun 4y ago
  The difference with software is that you are not allowed to look at the skyscraper, because it is the intellectual property of another company.
  - jameshart 4y ago
    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?
    - jimbokun 4y ago
      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.
swiftcoder 4y ago
> 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.
- chipsa 4y ago
  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.
cnity 4y ago
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.
- mikepurvis 4y ago
  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/2020/day-19/src/main.rs https://github.com/mikepurvis/advent-of-code/blob/master/202...
  - cnity 4y ago
    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).
    - fartcannon 4y ago
      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.
bodge5000 4y ago
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
- mikepurvis 4y ago
  > 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.
  - bodge5000 4y ago
    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.
Zababa 4y ago
> 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-researcher-discovers-integration-gets-75-citations/ https://fliptomato.wordpress.com/2007/03/19/medical-research....
HWR_14 4y ago
> 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.

shikoba 4y ago

> Github projects are any more representative of the work They are, that's the moment you see how the person code when she/he is responsible. You see the real skills and potentials of that person.

jameshart 4y ago
I disagree profoundly with this assertion. On a personal project there is no accountability. The developer didn’t have to understand what someone else wanted and try to figure out how to make it real. They set their own goalposts and had freedom to move them at will. You have no idea what their ambition was. Adam Savage had some interesting insights relevant to this in the context of evaluating model makers and artists for special FX work. While portfolio pieces showing their own concepts or creations might show off heir basic craft skills, it doesn’t show that they can create something to fulfill someone else’s vision - and that is the job. So what you want are portfolio pieces where they have drawn or built something recognizable - a replica or a scale model or portrait or something. Because that shows they can direct their skill to a particular goal. You know what they were trying to go for, and you can tell whether or not they nailed it. Mostly I’m hiring for developers to work in a large team, within a large organization. What they can accomplish when left to their own devices is scarcely relevant to what they will be able to do in that work environment.
- shikoba 4y ago
  When I see undocumented project that doesn't build, I know that the developer doesn't care about the quality of his work.
deleted 4y ago
[deleted]
xboxnolifes 4y ago
> They are, that's the moment you see how the person code when she/he is responsible There is no responsibility in small side projects. I write better code during my day job because I know other people will eventually have to interact with it.

mauvehaus 4y ago

I don't even code professionally any more, but when I gin up some code to solve a problem for myself in 20 minutes, I'll definitely try to clean it up before I throw it up on GitHub. I don't get any competitive advantage or economic benefit from my code, so maybe it's different for me, but if somebody finds my stuff and wants to use it, I feel like it's basic courtesy to not hand them something I vomited onto the internet. If you just want an offsite backup for your noodling around, make it a private repo; the contributor limit won't be a problem. If you're putting it out for the world to see, take the time to comment it, put a little polish on it, a decent README, and a license. If nothing else you'll be starting from a place of sanity if you ever have to revisit the code.

pc86 4y ago
I disagree but want to explain why. I don't view GitHub as a place to show off your code, or a place to find new code, or whatever. It's where my code is stored. I trust what's on GitHub more than I trust what's on any server, or any laptop, or running on my dev environment right now. As such, the idea of "cleaning it up" before putting it on GitHub seems backward. Code gets committed as soon as it's written, and if it gets cleaned up that history gets saved too. If somebody wants to pull my shitcode down that doesn't even have a readme, that's on them.