#[1]Dormeo Ergo Sum - The blog where I talk about nerdy computer stuff
(BUTTON) Toggle navigation [2]Dormeo Ergo Sum
* [3]About Me
* [4]Portfolio
[5][descartes.png]
Code Shame
Should you share your embarrassing code?
Posted on January 31, 2020
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 feat. 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 ([6]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 [7]Pinger.
Screenshot of Pinger
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. [8]wlcmd is a similar repository I
worked on around the same time.
Screenshot of wlcmd
Uploading this code to Github wasn’t only my introduction to Github but
also git! At university I had to use [9]CVS, [10]SVN and [11]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. [12]VVVVVV, [13]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.
Got any comments or feedback? Feel free to go over to the [14]Hacker
News Discussion and let me know your thoughts!
Tags: [15]coding [16]github [17]git [18]source-control [19]development
[20]developers [21]confidence [22]growth [23]productivity
* [24]← Previous Post
Brendon Body • 2020 • [25]brendonbody.com
Theme by [26]beautiful-jekyll
References
1.
https://www.brendonbody.com/feed.xml
2.
http://www.brendonbody.com/
3.
https://www.brendonbody.com/aboutme
4.
http://portfolio.bbody.io/
5.
http://www.brendonbody.com/
6.
https://github.com/bbody-old/
7.
https://github.com/bbody-old/Pinger
8.
https://github.com/bbody-old/wlcmd
9.
https://en.wikipedia.org/wiki/Concurrent_Versions_System
10.
https://en.wikipedia.org/wiki/Apache_Subversion
11.
https://en.wikipedia.org/wiki/Azure_DevOps_Server#Team_Foundation_Version_Control
12.
https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-code-game-development-terry-cavanagh-release
13.
https://gist.github.com/nikcub/3833406
14.
https://news.ycombinator.com/item?id=22234999
15.
https://www.brendonbody.com/tags#coding
16.
https://www.brendonbody.com/tags#github
17.
https://www.brendonbody.com/tags#git
18.
https://www.brendonbody.com/tags#source-control
19.
https://www.brendonbody.com/tags#development
20.
https://www.brendonbody.com/tags#developers
21.
https://www.brendonbody.com/tags#confidence
22.
https://www.brendonbody.com/tags#growth
23.
https://www.brendonbody.com/tags#productivity
24.
https://www.brendonbody.com/2020/01/23/dogfooding/
25.
http://www.brendonbody.com/
26.
https://deanattali.com/beautiful-jekyll/
