Comment by SadWebDeveloper | Hacker News Reader

Comment by SadWebDeveloper | Hacker News Reader

SadWebDeveloper

We live in a time were everything gets "community reviewed", jr devs like to post everything they do on github/bitbucket/etc, fork someone else code and comment on issues aka "Social Coding" just to get people to "praise them" and to score "internet points" but historically coding has been an a "alone skill", despite years of people advocating "pair programming" or some "agile" shit, the most useful codebases come from devs that isolate themselves on a topic, solve the problem and came with a solution. In the old days i used to code "things for me" not for everyone but since the era of "Social Coding", everyone pressure you to code for everyone and i have been only disappointed with people bashing "my code" because it's not "unit tested", made in "go" or "rust", etc... my advice for everyone that feels the same, is to stop "contributing" on github and start doing things for themselves, stop listening to the crowd and start living outside "the grid".

I have encountered this too. Some of most useful personal coding time is spent to exploring something new or solving a real problem with a quick and dirty solution. At no point do I set out to create a full polished, deliverable thing. I don't even know if I will solve my problem or understand the new thing! Why publish such code? A carpenter doesn't varnish and sell every single bit of wood that is practiced or worked on nor an artist present every single sketch.

Now imagine that to be hired as a carpenter you had to first prove that you have worked on dozens of pieces of wood before anyone would even consider you. Of course, the analogy falls apart here because we can expect most carpenters to have produced finished products, but most finished software products are highly complex and can take years to complete. Worst of all, these products exist in a marketplace where cynicism reigns: "Why did you build that? We already have three hundred of those. Quit reinventing the wheel!"

Do we complain when a carpenter builds a nice stool because there are already enough stools in the world?

Many companies now expect a GitHub history, as if that alone determines your value. It's no wonder people publish everything. They need to establish that they're doing something, even if it isn't master level "carpentry."

> Worst of all, these products exist in a marketplace where cynicism reigns

For better or worse, that cynicism is a natural outcome of the environment.

Imagine if there was a global service in the furniture market, called OS, to which you subscribe, and it lets you browse through a catalog of all pieces of furniture ever created, and order any one you like, for free. It's still desirable for carpenters to hone their crafts by making n-thousandth iteration of a stool, but were one to publish such a stool to the OS, everyone would immediately ask: "why did you publish that? We already have three hundred variants of those!".

This is how it works in computing industry. People will commend you for doing side projects for learning, but if you try to release something as a product, it will be immediately evaluated against existing alternatives. As long as you mind the difference between publishing code on your personal site (or Github profile, etc.) and publishing something as a product for others to use, you won't encounter the criticism.

I don't know how others approach Github profiles, but personally, when I view someone's profile, I assume everything there is side projects and playing around, unless it's clearly marked otherwise.

> Worst of all, these products exist in a marketplace where cynicism reigns: "Why did you build that? We already have three hundred of those. Quit reinventing the wheel!"

I've been sitting on a bit of rhetoric in case that comes up, though I've been blessed not to need it. Regardless, let me share the rhetoric -- just in case someone finds use for it:

"Put bicycle wheels on a cement truck. Put airplane wheels on a skateboard. Put train wheels on a wheelbarrow. The metaphor about reinventing the wheel doesn't go very far -- because the wheel has been reinvented many times, and thank god for that. I like having trains and planes and bicycles and trucks and skateboards and wheelbarrows. The world would be poorer if they all used the same wheel."

Worse, people frequently put truck wheels on wheelbarrows because they're the new hot thing.

Edit: Thanks for sharing. I will use this some day.

Yes, I think this very thing when people try to commoditize software components by analogizing them to a wheel. It works in some places (I wouldn't want to write a custom Redis or an RDBMS) but in most places, it falls down.

All the people I've heard use that analogy don't know what they're talking about when it comes to software development. I think it comes from the "Taco Bell" MBA types. They're the same people who think WordPress will put all web developers out of business.

It's frustrating to see the art of software development regress so much.

> I think it comes from the "Taco Bell" MBA types. They're the same people who think WordPress will put all web developers out of business.

And then on the other end of the spectrum are 'programmer types' who think WordPress is never a good solution because it's shitty for their particular use case.

Unfortunately most businesses these days rely on MBAs to make those decisions. Most MBA tracks don't even offer software development courses. They offer Accounting, Finance and Marketing, but not software development. That's funny because all of Accounting, Finance, Marketing and especially Operations run and rely on software systems, many designed and/or customized in house. It's a huge gaping hole in management knowledge in the US and it shows.

http://www.hbs.edu/coursecatalog/

Start-up managers don't want a "master carpenter."

They want a replaceable journeyman who smacks a few nails and strings together a few prefabricated solutions.

There are pros and cons. And, as for stools, well, these journeymen "coders" have polluted GitHub with quite a lot of stool.

Amen. "Everybody can code" is toxic thinking. If you can't chisel down a problem without importing half of NPM and a sprawling tour of GitHub/StackOverflow, then you are part of the problem.

Different problem spaces call for different solutions. Many of the problems programmers at medium-large companies face in practise are problems of communication, coordination, consistency, and code organisation.

So the question to ask is whether your code is having the impact like that which it should. Does this code make you (and/or your employer) enough money? Does it have enough impact on the world, if you are not doing it for money? If so, then you are righteous in this course of action. Otherwise, there may be a risk that you're That Guy who thinks he's all that but isn't and ends up on thedailywtf.com. We really can't tell from here :)

Most of the things you complain about are tools for helping a team (or a community) work together. If you do not do that, and instead produce software in isolation, you may in fact have no need for practices like code review. You may also have a reduced need for unit tests. It depends on your product's lifecycle and complexity.

Myself, I'm working at a payments service provider moving <BIG> amount of other peoples' money daily. We have unit tests. We have code reviews. We try not to break our stuff.

(That said, choice-of-language whining on a project that's not yours is almost always unalterably lame.)

You are talking about programming at work, this is a different place that requires a different mindset to approaching problems, m talking about side projects, the ones you do to learn, fun or to solve a common problem you have, developing at work it's usually the only place were you can't innovate, nor "become better at" something, it's driven by experience and profits.

PS: Without offense but you sound like a management robot, all those "big words" usually come from project leads who don't code, just "integrate" code.

"big words"? are words like "lifecycle" and really project-lead words or are they just indicators of "i have worked on soft-appliance software that releases on CD periodically, and also with continuous-deployment web services, and understand this as a defining factor?" Is that really any more ridiculous and managementy than putting "code review" in scarequotes? :/

And your point is? besides self-aggrandizing yourself there is no point related with the original topic of my comment nor yours.

This is exactly the way I've gone - I have a "projects" folder full of shit that just solves a problem for me in the quickest and mentally easiest way possible. I go learn new technologies only when they improve my ability to do that.

I've started doing this as well, and I'm finding often my solutions end up being simpler, better and have less dependencies than the go-to solution anyway.

For example, here's a React 'collapse' component, as people commonly use for accordions.

https://gist.github.com/JonathonAshworth/b401810b965149348d0...

It has 1/10th the code of rc-collapse (the 'go-to' solution it seems), and 4 less dependencies. And it's simple enough that basically any competent Javascript programmer can edit the code if they want slightly different functionality.

Importing NPM modules for this stuff is madness

thank you for yanking the words out of my mouth, thank you for restoring some of my faith in humanity, this comment just fucking rocks!

I've been extremely depressed about this whole 'thing' you described and I wasn't really able to pin it on a paragraph or thought. When I read your comment I literally saved it and said to myself "there are people out there that think like me, i am not alone."

Thank you. I don't know if I'm not sounding rational but I just really wanted to acknowledge your comment. keep at it.

https://www.youtube.com/watch?v=Go-jJlGd1so

Reply on news.ycombinator.com