22

Code Shame: Sharing your embarrassing code

 4 years ago
source link: https://www.brendonbody.com/2020/01/31/code-shy/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

A friend of mine has recently been working on his own game engine, I don’t know much about game development but to me this seems like an impressive feet. I have been encouraging him to put his code up on Github (even if it is a private repo), so I can look/help. He has been somewhat resistant which has made me reflect on when I started putting things on Github.

I think most of us cringe when we look back at our old code. A while ago I decided to clean up my Github profile as I had a lot of old repos that I haven’t seriously worked on in years or forks that I never touched. Looking at some of my old repositories made me kind of embarrassed but instead of deleting them, I decided to keep them and do a little cleanup:

  1. I edited their README and added a screenshot (if it made sense)
  2. I setup CI (if it made sense)
  3. I setup a demo site (if it made sense)
  4. I added a binary (if it made sense)
  5. I moved it to another Github Organization ( bbody-old )
  6. I archived them

I seriously considered outright deleting them. Most were hackathon sites I spun up over the course of a weekend or things I built while I was still in university. I decided not to because these repositories represented and demonstrated my growth. I think the repository that represents this the best is Pinger .

fyQzum6.png!web

The wxWidgets interface ages it a bit but Pinger was developed in 2013. In my internship at the time, I had to do a lot of testing with remote computers. When updating the software, it would automatically restart the computer. Once it turned back on I’d need to reconnect, which I could never really tell when to. The waiting and repetition of attempting to connect forced me try and solve this problem. So in my spare time I developed a program which would:

  • Monitor a list of IP’s
  • Intermittently ping if alive
  • Intermittently port scan UltraVNC port
  • Open UltraVNC when double clicked
  • Allow basic configuration
  • Store addresses

Despite a few stumbling blocks, it eventually became an integral part of my work. I scratched my own itch and it allowed me to do my job more efficiently with less repetition. wlcmd is a similar repository I worked on around the same time.

yu67van.png!web

Uploading this code to Github wasn’t only my introduction to Github but also git! At university I had to use CVS , SVN and TFVC at work.

I am still not sure why I uploaded them to Github but I am glad I did, I think putting my code out there definitely made me more confident. At the time I was still at university and was somewhat protective of code I wrote. I felt bad code was a reflection on my ability, but experience has taught me that it is usually a reflection of circumstance. Those 2 tools despite being very simple, solved a real world problem I had. The reason the code isn’t great is because I hadn’t done much real world coding. The reason my hackathon code is not up to scratch, is because of extreme time pressure. Any shortcuts taken was in order to provide a demo of the business case rather than my technical chops. One of my biggest fears was that people would belittle me or my code… And guess what? Those repositories have no comments/issues from other people and next to no stars/forks/watchers! My fear was unfounded.

I summed this up to my friend as:

  • No-one if going to leave comments on your code saying it is bad, if they do it means you made an impact e.g. VVVVVV , Facebook
  • A hiring company care a lot more about a project that works and does something than a repository filled with “perfect code” (if there even exists such a thing) that does nothing
  • Other devlepers understand if it is a work in progress
  • It is good git practice
  • Others can help you

Despite being somewhat shy about sharing my code, once I got over the initial hurdle of sharing what I built, I became a more confident developer. It definitely leaked into my professional career technical tests become less daunting and code reviews with peers is a learning experience not an adversarial experience.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK