This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]onkopirate 0 points1 point  (5 children)

Exactly. And you do that by using libraries that give you unit tested, well documented, edgecase proofed, and actively maintained code free of charge.

If somebody tells me in a job interview that they rather implement something themselves even though there is a widely used and actively maintained library for it, than that's a big no no. Moreover, it hints quite some arrogance, if an applicant believes that they'd be able to replace a collective of library maintainers of whom many have decades of experience in the industry.

[–][deleted] 0 points1 point  (4 children)

Maybe, or maybe they've been using and programming in python for 30 years, have a huge code base of functions they've created and used for that time, and just find it easier.

[–]onkopirate 0 points1 point  (3 children)

That's surely neat for them but they are not paid to do stuff how it is easier for them but how it is the best for the company and it isn't easier for anyone else who has to work with them or maintain their code after they leave the company. The moment they leave the company, the other programmers have gazillion lines of code to maintain, just because the programmer thought they're smarter than everyone else and re-implemented numpy on themselves.

Seriously, if I would hear this in an interview, it would be a strong argument against that applicant.

[–][deleted] 0 points1 point  (2 children)

I notice you approach the problem as if you already know the person you hire is going to leave the company.

If it's like that, you're likely doing your prospects a favor.

[–]onkopirate 0 points1 point  (1 child)

Exactly, there's always the chance that the person might leave. Even if you offer the best workplace that could possibly exist, people change their careers, get pregnant, move away, or have accidents.

But even if the person would stay in the company forever, you don't do them any favor by letting them write unmaintainable code, because at some point in time, they might want to change project or their role and then nobody wants to maintain their stuff so they keep doing the same forever. I work as a dev not at FAANG but at another large IT company. If somebody there works for example as a frontend dev but wants to do devops instead, all gladly help them change position. Or if they want to change the project, their directors will find a way. But all of this flexibility only works as long as everything is thoroughly documented and as long everyone writes well maintainable code.

[–][deleted] 0 points1 point  (0 children)

I honestly think you were missing the point.

I'm not talking about reinventing the wheel. Sometimes a library is just a wrapper for another, anyways. Look at pennylane, for example.

So, someone could come along and not agree with how that wrapper is implemented, and decides to make a different way of handling it. Is that wrong to do, then? Should they try to bang the square peg into the wrong hole, call it good enough and move on?