Ask HN: Embarrassed to open-source code because of code quality? | Hacker News Reader

Ask HN: Embarrassed to open-source code because of code quality?

12 pointsanonymousrex14 comments

Folks, like many here, I'm a self-taught developer.

And while I've been doing it for a few years now, I've generally prioritized outcomes over technical elegance, so I often hesitate to learn the trendiest frameworks & instead just focus on shipping.

This results in a fair helping of code that works well but might use untrendy frameworks, sub-optimal structures, etc.

I now run 2 ventures with decent traction. While I never handle sensitive/financial information, my beliefs in privacy, transparency, and freedom require making the source available (at least for the local client software like desktop programs, smartphone apps, etc).

But I wonder about the downsides...how would you (as a user, or as an employer) think of code that technically works (doesn't crash), practically works (gets users, makes money, etc), but looks kinda unprofessional (not super-concise, not terribly efficient, etc).

Every project I've come across on GitHub looks like it was built by people who are so much more experienced than me.

I've heard some founders (the Foursquare one comes to mind, but I know there are others) say similar things (i.e., they're "lousy" at programming and can only do "just enough" to get the job done) but they didn't make their code available to the world. Then they raised millions and hired great programmers to fill their gaps.

While I plan to make a decent amount of money, I'm not betting on unicorn status. This is a different level of scrutiny, and while I'm confident the principle of open-sourcing my code is sound, I'm not so confident if the code itself will live up to the reputation of the services it provides.

Any thoughts?

I believe there are four reasons why people open source their code, and what the reason is directly affects the quality of what they put out in the open;

1. They want their code to act as their resume. These people put a ton of effort in to making their code work well, look good and read nicely.

2. They genuinely believe in the Open Source movement, and want to share what they build so other people can add to it, improve it, and use it more freely. Their code looks good and reads well, but often not as well as the people in group 1 because the results actually matter more than the code.

3. Pure vanity. They want to be famous and think making their code open is a way to build their rep. They'll give things a bit of polish before putting it on Github, but often quality is second to quantity.

4. They put things on public repos without really caring whether anyone sees the code because they write the code for themselves, so it's technically open source but only because it's not private. The code is usually really hacky but no one sees it so it doesn't matter.

By the sounds of things you're in the second group. In your position I'd tidy up the code as best as I can but I wouldn't stress if it's not the best there is.

(I'm in group 4)

Thanks. I'd add a 5th group—trust & verification. Maybe that could be considered an extension of #2, but the ability to know (and trust) the integrity of the software your're running on your hardware has become the most important aspect of open-source software for me as a user.

Now, as a vendor, I want my users to have the same piece of mind. Both of my projects are predicated on privacy, so there's a solid business case in each case.

It's not technically open source if it's merely visible. It's only technically open source if you explicitly license it to be so.

Generally speaking, people in group #4 throw an athena license or BSDL on it (though sometimes they'll throw a GPL or something on it instead).

Group #4 accounts for most individual open source projects (though not most code, since big projects tend to be huge); we discount it at our own risk.

Most of the work I do for myself is on Github and it almost never gets a license. The one thing I have added to PyPi got MIT because according to the online license picking tool I used it was the most open.

I actually intend to more widely open source that lib but I have so many projects I'm working on currently it's hard to pick one.

In my corner of the internet most projects use the ISC license that Node sets as a default. I have no idea if that's ever been challenged in court, but at least in theory everything is open unless someone has specifically set it not to be.

All code sucks. Your code, my code, everyone's code. For every codebase, there exists a significantly loud contingency of eyeballers who will hate it. I've gotten into arguments with unpleasant people who hate GNU Octave's code. The very first time I showed my C++ code to someone, which solved a problem in what I thought was a clever way, their only response was to say "why are you using cout, use printf instead, and what's with the horrible indentation format?"

Code shame and code shaming is real. But this should never prevent code from being published. Your users can always benefit from having the code available, so you should give them that code.

Heck just ask anybody on a code review. In my experience, they are simply code shaming and one-up-manship institutionalized. No effort made to address feature or correctness. No, endless squibble about names, indentation and which particular language feature they prefer.

I know two companies that are hamstrung at this very moment, by endless code review nonsense delaying projects indefinitely. They think more people will help. Ha. </rant>

> Your users can always benefit from having the code available, so you should give them that code.

Thanks. This is the mindset I plan to stick with!

Have you ever seen an apache project? The norm for code quality is abysmal, even in open source (where it's much better on average than proprietary hacks).

HR generally doesn't have the training to distinguish good code from bad code, and will be counting your repos or the lines of code in your repos if they look at your github at all.

Ultimately, the bigger issue is whether or not you feel like your competence should disqualify you from a position. If you feel that way, then you should do something about it before applying for jobs. A good way to improve your skills is to fix the code you've already written, and doing that in a public repo demonstrates progress in a way that technical peers can appreciate.

(Re: trendy frameworks -- fashion has nothing to do with fit, and trendy frameworks are overhyped specifically because people use them when they are inappropriate for the task at hand. It's not hard to pick up a new framework on the job if you're asked to do so; I would avoid trendy frameworks and focus on the basics until somebody who controls your paycheck tells you otherwise. After all, which framework is currently trendy is liable to change inbetween getting a job and being able to start work, and the people making decisions about which frameworks will be used are almost inevitably tied to the trend cycle but ten or fifteen years behind it.)

Ironically, I was having this same conversation with my fiance this morning. Lately I have been watching/listening (or at least having it playing on a screen on my other computer) Twitch programming channel. I switch between programmers and usually try to find something that is somewhat interesting to me to at least listen to. She asked why and how I could listen to that while working. Not sure why I switched from Spotify to Twitch over the last couple weeks, but I have found myself twice as productive so I am not questioning my choice. Her asking me though made me stop to reflect on that switch.

I am by no means a "great" programmer, but I can write code and would consider myself a good programmer. Like you said, it may not not always be elegant or the most efficient, but it works and gets the job done. My biggest problem is that I hesitate to launch/release because I second guess myself sometimes on the overall quality of the code. I am also hesitant to release open-source code for similar fears/lack of confidence.

Watching Twitch though I see others writing code. Some of them write better code than me, but for the most part the quality of code I see is equivalent to my own. They each have their own style and focus. Some are better commenting code while others write more efficient code. In the end though, 8 out of 10 times I find them writing the exact same code I would have written. Listening to them talk though gives an insight into what they are thinking. What I see/hear though is people who are confident enough to just code regardless of what others think. Sometimes someone in the chat will provide feedback on a better way they could do something or a general observation that provides valuable feedback. This confidence to just code without regard to what others think combined with seeing that many of the coding decisions they make are similar to my own has increased my productivity. Seeing and hearing all this has made me not second guess my coding decisions as much and I find myself writing code much faster.

Interesting insight. Thanks for sharing!

Watching others in the process of coding sounds like an excruciating level of transparency for the subject. Mine would have to be X-rated for all the language during the frustrating periods, ha.

Chances are it's just impostor syndrome. Nobody's gonna care unless there are hideous hacks everywhere. When reading other people's code the first instinct is to assume everything is there for a reason. Given the effort it takes to critique someone's code, if somebody does - you're in luck.

You could ask a friend to take a quick look if it makes you feel better.

> I'm not so confident if the code itself will live up to the reputation of the services it provides.

Then don't open source it.

If you are running a business then it should be a financial/business decision. Is there any financial/business reason to open source it?

Weigh the opportunity costs and make the decision.

Reply on news.ycombinator.com