b17z

@b17z

My misadventures through the digital world.

4,187 words

@b17z_ Thank
You'll only receive email when b17z publishes a new post

On Evan Miller's "You Can't Dig Upwards": C'ing Programming

This was inspired by Evan Miller's "You Can't Dig Upwards"

I urge aspiring and seasoned programmers to fully read through Evan Miller's You Can't Dig Upwards. It is a good read and explains my general feelings when it comes to computer science.

In retrospect, learning stick shift was a prudent investment of time, even though I’ve never had to prove it to society by (for example) driving a stick-shift ambulance full of orphans while avoiding heavy gunfire. Driving stick is just a good skill to have. More people should have it, in my opinion.

Before I begin, I'd like to point out what he said gave me quite the awesome imagery and I will be trying to do this in the future.

In all seriousness, his post sums up how, in the computer science world, Python is one of the first languages we learn, which almost guarantees that programmers will never learn C and he believes this to be a bad thing.

He also notes he is in the minority with this opinion. I'd like to point out that he's not alone and I share his opinion.

He argues that

Programmers who only know Python lack a proper mental model of how computers work

I believe this to be true. I'm not trying to shit on people who don't know C. There are very talented people who go throughout their computer science journeys without ever touching C. I'm not trying to prop myself up either. Truth be told, I barely remember C. While I am writing this, I am getting flashbacks to my architecture classes and the pain of debugging C code and getting constant segmentation faults. Pretty sure I have programmatic PTSD from my memories of C programming.

However, after wrestling with the devil by doing the Malloc Lab from Carnegie Mellon University, I remember feeling like a peak programmer. Doing that lab was one of my mentally taxing things I have done in my computer science career. That is, until I took Advanced Object Oriented Programming at my school a year later. I'm pretty sure I cried a few times during that class. That class should have been renamed to "How to Build Your Own C++". But as I said, I never felt better about my skills as a programmer after those classes.

But after those classes, I never did anything similar again. There's a reason I keep saying I have to re-learn everything. I don't think I retained much of my skills. I also have been slacking off from doing the appropriate work at home but have been doing better with it recently. You can see my post on Grading Myself Honestly on the Programmer Competency Matrix (By the way, I am a little more rusty than I originally thought so I am going to have to update this again and then haul ass into scrubbing away the programmer's rust).

Understandably so that sometimes, in industry, we don't "use" the skills from the computer science degree. We see the joke all the time, "We never use algorithms in industry but we get interviewed on them!" However, I think we need an understanding about how the computer works at any level of our careers or undertakings. If we want to build good software, understanding the underlying is a must.

However, the culture of "just use Python," "computers are fast enough," and "throw hardware at the problem" is creating a deeper systemtic problem: as a result of teaching Python first, and denigrating C, fewer and fewer people will want to become professional programmers.

I hope Evan hasn't disappeared from the planet with that statement.

I'm the type of person that really doesn't like blackboxing or abstracting - sometimes to a fault because affects the speed at which I do things. I like understanding the underlying. I am curious about the underlying. Maybe you can say I am a glutton for punishment. Sometimes I think Python is just magic. Shit just works. That's great and all. I even argue that if you want to prototype something really quick, you should really use Python. But I don't think it's conducive to really learning as much as you can from computer science.

You might argue that it's not needed, especially in today's software landscape. This is true. Technology moves quickly (how many Javascript frameworks have come out during your reading of this?). It is currently, economically infeasible to build extremely good software especially if it runs the risk of being something that no one wants. That is a huge waste of resources. So, the solution is to throw quantity at problems, not quality. However, I'd like to present a fair counter argument. If we establish that foundation of understanding how computers work, I argue that we will be better equipped to dole out solutions even faster than we are doing now. Sure, it's a lot slower to do this but we'll accelerate faster later. However, this is generally not how industry (and the world) works.

I believe that it might be time to revisit this fast paced world and try to slow shit down. I'm not sure how the economics would work around this but I mean how many articles have come out during your reading of this that lambasts some company with poorly written software because there was a data leak or something? It seems like everyday there is something new popping up with poorly functioning software. I'm pretty sure the economics behind poorly functioning software isn't pretty.

This especially comes into light with new technologies springing up. People don't understand the underlying but then want to build everything with it. I see this in the blockchain space. "X but on the blockchain." How about understanding what blockchain is first? Don't get me wrong, building stuff is great. It flexes a mental muscle. But thinking deeply about your solutions will flex an even bigger mental muscle. Deep thinking usually constitutes well, digging deeper into the train of thought. So, in the case of blockchain, understanding what it is, how it works, how it was built will better equip you into producing good solutions.

I should point out that I am not discouraging a head first dive into new technology. I advocate such a process. The best way to get acquainted is to dive in but I argue that we have to go deeper after we get acquainted.

Taking this back into the context of Miller's post, understanding how a computer works will help address the quality not the quantity.

In industry, you just need to get shit done. Python or Java get shit done quickly. No need for any extra understanding except understanding which modules and libraries facilitate the solution. I argue that we should go deeper whether it is a proposal at work or doing your own shit at home. I find programming the most fun when I am digging deeper into solutions.

There's a mistaken notion that programming is most enjoyable when you're doing a diverse array of things using the smallest amount of code, leveraging client libaries and so forth. This is true for people trying to get something done to meet a deadline; but for people motivated by learning - and who aspire to be extremely good programmers - it's actually more fun to create programs that do less work, but in a more intellectually stimulating way.

I think we can achieve both but maybe I am just optimistic. With how fast technology is moving (I am pretty sure that was the sound of a quantum computer being tweaked), it's going to exacerbate the speed at which we try to do things.

It's that mental model - rather than the C language itself - that will enable you to poke through the abstractions created by others, and write programs you never thought possible.

I don't know about you, but that sounds awesome to me. So, for my relearning, I have committed myself to relearning C and going deep into the underlying - the architecture, the operating system, the memory, etc. It's going to be a slow process but a quote that really has stuck by me is "Don't overestimate what you can do in a day but don't underestimate what you can do in a year."

Development Diary 03 | 10 | 2018

Misadventures in Go

  • So I downloaded using the instruction on the go website, and clearly didn't pay attention to create the stuff in the directory I assigned it to. So, then I typed the go build command and it prompted me to install go using sudo apt get.
  • go env to show a list of Go values
  • I need to set the GOPATH
  • I should probably have a rough idea of what the go environment variables are.
  • Which reminds me: I should also know what the hell the bashrc is and how it control the environment.
  • Which also reminds me: I should also understand the vimrc as well.
  • I really don't know/remember shit but thankfully my current ventures are helping me with that issue.
  • I did the basic, "Hello World" program in Go
  • It's telling me to look at How to Write Go Code before I deep dive
  • Go Commands
    • build: compiles packages and dependencies
    • clean: removes object files and cached files
    • doc: show documentation for package
    • env: print Go environment info
    • bug: start a bug report
    • fix: update packages to use new APIs
      • This is interesting
    • fmt: gofmt (reformat package sources)
    • generate: generate Go files by processing source
      • Interesting
    • get: download and install packages and dependencies
    • install: compile and install packages and dependencies
    • list: list packages
    • run: compile and run Go program
    • test: test packages
    • tool: run specific go tool
      • Interesting
    • version: print Go version
      • Very sure I will be spamming this
    • vet: report likely mistakes in packages
      • Quite interesting
  • Compile packages and dependencies usage:
    • go build [-o output] [-i] [build flags] [packages]
  • Go is very anal about organization, which is fine by me.
  • I should bookmark that page.
  • Code Organization:
    • Keep everything in one single workspace
    • A workspace contains many version controls repos
    • Each repo contains one or more packages
    • Each package contains of one more go source files in a single directory
    • The path to a package's directory determines its import path
    • Different from other programming envs because every project has a separate workspace and workspaces are closely tied to version control repos.
      • Basically I'm going to confuse and screw myself much like when I code in Python vs. C++ and add semicolons to Python code.
    • Workspace:
      • src: contains Go source files
      • pkg: contains package objects
      • bin: contains executable commands
  • Upcoming To Do List:
    • Continue with examples from the Go site
    • I have the K&R Go Book so I will start going through that
    • I also have the Go Web Programming Book so I will keep doing web examples in Go

Before the Big 'One Oh'

Memories from Before I was Ten

My father passed away when I was nine. Before that, I remember him trying his best to keep up with my growing up and my mom doing her best to do the same but also take care of him. My life before ten contained a lot of hospital visits and my mom helping my father in and out of a wheelchair, walking up (or down) 2 flights of stairs to the third floor, and my mom doing a double trip to get that wheelchair up (or down) those same 2 flights of stairs.

One of my first (good) memories of my father was when I was running around in one of the fields of our local park and my father and mother were sitting down on a bench and he was feeding pigeons. I later learned they are basically rats with wings. However, I thought it was cool. My father was like a tree. He held out all his arms and birds would just perch on top of him. I thought it was super cool. I believe this was my first "recalled" memory from when I was a kid. I am also very sure I was around four years old.

One of my first (bad) memories of my father was when we were inside our railroad apartment and we started to smell smoke. My father was already very immobile so when my mom was scooping me up to get out of the apartment, all I heard my father say was, "Just let me die." Imagine a four year old hearing about that. I don't know if I actually knew what he meant since I was four but clearly it imprinted in my mind. It turns out, someone downstairs left water boiling with a pot that had a semi wooden handle; at least, that's the story I remember. It ended up being a false alarm.

After that, all I have are just flits of memory of him getting sicker and sicker and my getting more stressed and upset.

My final memories of my father were the constant hospital visits after school and my mom arguing with nurses and doctors and my mom threatening to sue for medical malpractice.

I am sure the third to last memory I have of my father was when he was still able to talk and he told me, "Don't worry, son. I will live until you're 19th birthday." The next day, the second to last memory was him with a tube down his throat and unable to talk anymore. I got to touch his soft hand one more time. I got to see his blue eyes one more time. I got to see him cry one more time. And then the call at around 1 AM later a few hours after we left and more of my mom arguing with doctors and nurses; He died. I heard the heavy phone drop in my sleep, heavy crying sounds and I wake up heavy eyelids with my vision blurred because the tears were already there. Goodbye dad. I love you.

A Reflection on What I Need to Do Better Now 2 Years After College

On Recently Going to a Hackathon

Recently, I went back to my alma mater on behalf of the company I work for to try to scout some talent. The event we went to was a 27 hour hackathon.

A hackathon is a gathering of people - generally computer scientists, and software developers - in which, teams or individuals work on a specific project for an extended period of time. As mentioned above, this one lasted 27 hours. Some hackathons can go on for days or every weekend for a month. The project can be anything the creative mind can think about. At the end of the hackathon, the teams (or individuals) can submit their project for judging and earn awards. Awards can be in the form of money, prizes, job interviews, or a combo of all.

My purpose (along with my other crew members):

  • Help the talent with any questions they may have
  • Promote the company I work for as a place they should could consider applying to
  • Judge the projects

In the end, about 40 projects were submitted, and these projects were all very impressive especially given the timeframe. Some projects were simple web apps that would function like a brilliant business. Some would leverage cutting edge technologies such as neural networks, natural language processing, and blockchain. Some were a combination of hardware and software (robots). Some were simple games that were designed beautifully. The array of talent at these events is mind-boggling.

I was there once a few years ago. I did one hackathon and a bunch of coding competitions. I used to be fairly good. I used to be that guy looking at the companies sponsoring these events and thinking, "I'll be there one day." Well, here I am.

Reflection on Being Out of School for 2 Years

Sometimes I wonder if I should go back to school. If you have been following me (I won't be offended if you haven't), I've been saying how much I feel like I have weak foundations in my fields of study.

For the first 3.5 years of college, I studied chemistry/biochemistry. But after applying for an introductory course to computer science, I instantly loved it, and wanted to pursue it. The problem was that my family wasn't in a very good financial situation. The longer I stayed at college, the more financial strain I put on myself and them. So, for the next 2 years, I crammed in a math and computer science double major.

I'm a quick study. I picked up enough to be competent at what I do but I always felt like my skill had been dwindling.

Maybe it was the feeling of being overwhelmed about life, maybe it was the lack of confidence but for a while, I didn't really do anything to foster my skillset. That is, until I discovered blockchain.

For those of you who are not up to speed, blockchain is the underlying technology behind Bitcoin, Ethereum, etc. It helps promote a decentralized economy through trust-less cryptographic proof as opposed to the trust based system we have now (we have to "trust" banks and other third party intermediaries).

All of the sudden, I felt this spark that I haven't felt in quite a while. At first, I wondered if it was just the allure of new technology. I'm sure I'm not alone when I say that when a new technology comes out, I want to experiment with it. But this was different. I just wanted to be as knowledgeable as possible in the blockchain space. I found myself trying to read and understand the original whitepapers. I was looking up free courses (distributed systems) to re-up on my current skillset. I found myself delving into crypto-economics and the history of money. I even learned some trading skills. A jack of many trades (and a master of none... yet).

Realizations at the Hackathon

Judging the hackathon made me feel insecure for a bit. I'm standing there listening to freshmen and sophomores talk to me about their neural network project that detects fake news. I kept wondering in between judging projects if I am behind, if I am a dinosaur, if I should give up.

And then I realized:

  • This isn't a race; it's a marathon. Sure, I may be out of the gate late. I started the major late, and I didn't really start applying myself until last year. There is a mantra I try to live by: "Don't overestimate what you do in one day. Don't underestimate what you can do in a year." Recently, I started to ramp up my learning. This is what this space is; it's consistent learning. I try to make a little progress everyday. Incrementalism is one of the best ways to make progress.
  • I should focus on implementing. I shouldn't overwhelm myself with information overload. There is a lot stuff out there. But what I noticed about the people who succeeded in finish a project focused their time those 27 hours at delivering. I imagine during their breaks, they did explore around and did other things but for the most part, they focused on what their tasks were to make the project a success.
  • I should focus more in general. Going back to the previous point, it's sometimes hard, in the internet age, to focus. I bounce around the internet getting into a wormhole and lose track of time and what tasks I have to do.
  • I need to be real about my time. Time; the thing we all never have and spend time wanting more of it. This ties into the previous points. There's plenty of time to implement but sometimes I tell myself there is no time because of "how much I have to do." If I used my time as efficiently as possible, I should have many of those, "I need more time" issues.
  • I have to put myself out there more. These talent went into the hackathon with an idea, implemented it, and put it out there to be judged. They were open to suggestions, feedback, and criticisms. They wanted to know how to get to the next level. They wanted to know how to push themselves and their projects further.
  • I need to stop being a perfectionist. I have a perfectionism problem. A lot of the projects, even though they worked, would need more work to scale or need more work in general but they still submitted. My ego sometimes gets to me. I put it in my head that my project (or my writing) needs to be perfect the first time around. Nothing worthwhile is done perfectly the first time around especially not in computer science. I need to be comfortable with simple trial and error. Sometimes I'm so afraid to not be perfect that I barely even start or just abandon my ideas in the middle.
  • I need to be able to be a good improviser. I can try to plan things out as perfectly as possible (see: perfectionism) but rarely do software (and anything) projects go "according to plan." I don't know the future. I can't plan for things I can't see. What I can do is have the ability to pivot.
  • I need to be comfortable with "thinking in bets." As I mentioned in the previous point, I won't have all the facts so I need to be able make decisions with what I'm given. If I get "decision-lock", then I will end up getting nothing done.
  • I have to accept that I won't be correct all the time. If I made a judgement call, and it didn't pan out, I need to be comfortable with being wrong. I need to do a postmortem of the decision and learn from it. I should be comfortable with owning up to it publicly. I shouldn't be caught making the same error over and over again. If the decision ends up panning out, then I should keep that in my "book of successes" so I know what I can fish out if I face a similar issue again.
  • I need to properly assess risk. Most, if not all of life is about proper risk management. The decisions we make all come with its own set of risks. Are those the best risks to take on? What is my risk tolerance? I can't have everything so I need to be able to be comfortable with the something that comes out of risk management.

What I Believe I Have Done Correctly Recently

I think learning about blockchain in the middle of 2016 was a bit of a turning point for me but I shouldn't be doing good habits only because I am passionate about what I am doing. I should be able to do this consistently in all facets of my life.

  • So far, I have been more consistent with putting myself out there. I'm not doing it at the frequency I want it to be but I am making progress on that.
  • I've long accepted that I will be wrong a lot. I'm fine with putting my ideas/thoughts out there and being utterly wrong.
  • I get less decision lock.
  • I am less of a perfectionist than I was in college.
  • My focus is getting a lot better because I tend to read a lot of books and just use the internet as a tool, not the other way around.

What I Need to Work On

  • Consistency. I have to be able to do this day in and day out.
  • Perfectionism. I still get decision lock every now and then and it really stunts my progress.
  • Implementation. There is a saying that people should be "doers." I think that's a good start but I think we need to be finishers as well. The work is never finished obviously but we need to finish our iterations. If it's an MVP, finish that. We can get into a new iterations after that and finish those.
  • Risk Management. More stuff to do, more decisions, need to keep building the framework to properly assess risk.
  • Ego. Well, I think many of us have to stunt the ego.

Concluding Thoughts

I'm sure there are a lot of things I haven't covered in this brief reflection. As I go along, I will keep adding postmortems and reflections on the many things I will inevitable do. I do hope that this reflection will help some of you find your blinders. We all have them. It's about what we do when we find those blinders. In addition, I hope for those of you that had/have similar feeling to what I had during the hackathon that you feel more at ease.