DEV Community: Austin Hardaway

Book Recommendations!

Austin Hardaway — Fri, 10 Jan 2020 13:32:37 +0000

So I don't know if this will resonate with anyone else, but high school 100% killed all motivation to read books for me. As a kid I loved to read and I read during almost every free moment. Cue high school (or maybe junior high?) and suddenly teachers are telling me to read and what to read. Sudden stop. College wasn't any better. I mean I read for class (most of the time) but only the bare minimum and never for personal reasons.

Last year I decided to reacquaint myself with the idea of reading for enjoyment. Now that no one is telling me to read and after getting back in the habit I really enjoy it. So I thought in honor of those resolved to read in the new year, I thought I'd give some hot takes on some of the books I read in the yesteryear.

Admittedly there is a theme here. My path back into reading was computer history. I always wanted to take a computer history course in school and never did, and It's a topic I'm really interested in. I like to think it helps me see this moment in tech where I've started my career as a period that makes sense in a larger perspective. Would love to hear some thoughts of engineers who have been in industry for a lot longer!

The Soul of a New Machine

Can't take credit for this recommendation that honor goes to the one and only @jessfraz. In any case it is a wonderful read that really ignites a feeling of nostalgia for a time when the PC was a just a twinkle in the eye of an engineer. It is the story of a reporter looking in on an engineering team as they design, build, and test a new minicomputer. It's a story of internal company politics, motivating a team of engineers, and perseverance through the grind of setbacks. If you've done any professional engineering work this will resonate with you. If you've never done any and you want to know what it's like here is an (admittedly rose-tinted) example. Personally I felt extremely vindicated that some of the issues I encountered as an intern were brought up and that I was not the only one feeling them. As a matter of fact people have been feeling them for decades. Anyone who does anything in a technical field with a team should read this IMO.

A People's History of Computing in the United States

Riffing on Zimmerman's Peoples History of the United States. (An interesting read in it's own right.) This is the history of the start of computing in the US, from the perspective of the so often marginalized players. This is the story of Time Sharing and the people who formed the first computer communities. Spoiler alert-- It wasn't just white males from Stanford. This is a great look at the expansion of a computing culture that includes the voices of the women and students that used the first time sharing systems, formed the first digital communities, and wrote the code that made it happen. Too often the idea of a history of computers is the detailing of the Steve Jobs of the world stealing from the XEROX Parcs of the world.

This more academic entry to the list was well appreciated for adding the voices and stories that are unlike my own to my picture of my industry. And though this title is in premise a look at marginalized people in Tech, and it is. In an odd way this title also leaves a taste of nostalgia for the way things were.

Coders: The Making of a New Tribe and the Remaking of the World

I actually picked this book up at a Books-A-Million while waiting on my brakes to get fixed one rainy afternoon. I began reading with a very small picture of what it was about and barely put it down for the next several days. This one is rather unlike the others.

If A Peoples History made me think of stories and peoples that were not like me. This is the opposite. And by that I mean a related so hard to almost every story presented in this book. Thompson interviews prominent people in the industry to paint a picture of what 'coder culture' is.

This is a very affirming read for me. So many times during this read I found myself thinking: 'Wow, I totally do that and know people that do it also'.

It's also on the opposite end of computing history, instead of talking about BASIC and the Rise of time sharing, it's the post dot com big players. And if you follow the same twitter accounts I do then many of the names wouldn't be new to you. Good easy read.

Mythical Man Month

"The only useful book I read in college" - Cameron Howe (Halt and Catch Fire)

MMM on the surface, is a collection of essays on software engineering as a profession. While relatively light on tips and tricks revolving around the actual implementation of code, this book focuses on the more professional aspects. Managing a team with expectations and different visions. How to deal with a late project. How to focus on code integrity without sacrificing the timeline. Little gems of wisdom. MMM on the surface, is a collection of essays on software engineering as a profession. While relatively light on tips and tricks revolving around the actual implementation of code, this book focuses on the more professional aspects. Managing a team with expectations and different visions. How to deal with a late project. How to focus on code integrity without sacrificing the timeline. Little gems of wisdom.

Almost more intriguing than the wisdom offered, is how it's written. Many passages from this classic entry will literally give you goosebumps and motivate you in ways that software is not known to do.

If you are only going to read one book on this list, this is the one. 10/10 it's a timeless classic. The Moby Dick of Software

CODE

Code is a book about, yep you guessed it, code. And by that I mean encodings for the most part. Starting with the idea of encoding in it's simplest form and moving all the way to some pretty impressive discrete mathematics. Now it's not a discrete maths textbook. I found it a little light on some of the practice you would find in such a text. This is the Neil Degrasse Tyson pop-science astrophysics book for discrete math. Right at the intersection of wow this is cool and wow I don't care-- a line the author walks beautifully.

I enjoyed this as a return to the basics, a look at code that really truly starts from first principles and builds all the way up. This would be a huge jump start on the curriculum for most would-be Computer Science majors (With just enough detail to let you know what you're in for). As well as great gap finder for those folks with non-traditional educations or anyone who thinks they could benefit from a tighter grasp of computer theory.

In closing books are great and we should all read some more of them! These are some that I would recommend to anyone on this site. What about y'all?

2019 In Review

Austin Hardaway — Sat, 28 Dec 2019 05:45:45 +0000

Heya folks, Hope your holiday season went well! I'm sitting in the airport waiting for my flight home from the holidays. And since I'm apparently nostalgic trash I thought I'd take a moment and acknowledge the achievements of this year.
nostalgic

Achievements

Big life events this year, for one I graduated from the University of Georgia with a degree in Computer Science and Mathematics. Then I went on to get my first real full-time programming job.

I moved across the country and I furnished my apartment.

I completed three large software projects, One was used to grade assignments in the CS department at UGA this past fall semester. One is currently in the hands of its first users right now.

I completed a nanodegree, and I hit some large savings and financial milestones. And I started a blog.

This was a big year, a momentous year.

Failures

This was a good year, but it wasn't all good. I've got several areas to work on for next year. A huge area is my health. Having started my first full-time software gig means I'm also living my most sedentary lifestyle yet. And I failed to balance that with exercise, and a healthy diet. I ate and drank far too much at the end of this year.

In a larger sense that's indicative of a larger failure to maintain a work-life balance. I've done well at my job, but I'd like to start putting some effort into more areas of my life. Have more connections outside of work. And have more goals outside of software and work.

Overall I had a pretty good year. I have this image in my mind of doing this next year too.

How did your year go?

998 Good Bricks

Austin Hardaway — Fri, 06 Dec 2019 01:58:27 +0000

Kludge: noun &bullet; /klo͞oj/
&bullet; An ill-assorted collection of parts assembled to fufill a particular purpose.
&bullet; computing A machine, system, or program that has been badly put together.

Today I released my first application as a professional
developer. The product of 6 months of grinding to meet
deadlines, haggling with stakeholders, and more
setbacks than I care to think about at this moment.

I got it as a hand-me-down side project from a team that
clearly didn't have the bandwidth for it. It had no
documentation and no tests, which didn't matter because
it didn't work.

On the one hand, I got to learn frameworks I didn't
know. On the other hand, I had to use techs that I
wasn't comfortable with and that I wouldn't have chosen.

This is a story of failure. And victory. And of overcoming
circumstances out of my hands.

We don't always get to choose how we do things. We have
pressures from up the food chain. We have pressures to
use new technologies. We have pressures to meet
deadlines. When the deck is stacked against you, you
really have two choices. Do you get to work? Or do you
give up?

This was a learning opportunity. In more ways the one.
Sure I encountered tech I didn't know, but I'm talking
about more than collecting frameworks and learning
a cool new technique. I learned what not to do.

Never in my life would I want to build an application
like this again. I wouldn't wish it on my worst rival.
Everything that could go wrong went wrong.

I had to interface with existing procedures that were
out of my control and seemed tailored made to
antagonize my efforts. I had half enough time to finish
the product. There was a fundamental misunderstanding
of what it was I was even trying to build. When my
stakeholders and I finally got on the same page, they
changed the requirements. This was a crash-course
introduction to troubleshooting the process of software
development.

The end product certainly isn't perfect. There is less
code-coverage than I would have liked. There are almost
certainly bugs that will be discovered in the next month
of roll-outs. Certain functions take entirely too long
to finish, and unnecessary complexity is the standard;
not the exception.

I failed at designing an elegant system.

I failed at implementing that system smoothly.

I failed at planning.

I failed at testing.

I failed at being a professional engineer.

I had built a kludge.

However, I delivered a working piece of software that
accomplished the goals of the product owners. I
delivered it on time. In these two aspects, I succeded.

There is a story about a monk who lived in a monastery.
His first task at the monastery was to construct a brick
wall. Laying bricks is not easy. Keeping every brick
level and in line and straight and square is an almost
impossible task. Still, the monk tried his hardest
to make sure each brick was perfectly straight and
perfectly level.

After a long time, the monk had finished the wall and
felt a surge of pride. He had finished his wall. He
stood back, looked at what he had built and became
inconsolably distraught.

There were two bad bricks.

He had been so careful to lay each brick carefully so
that his wall would be perfect. The sight of those
two bricks ruined the whole wall.

So the monk goes to his superior and asks if he can
tear down the wall and start again. The elder monk
looked at the wall and said

Why would you want to do that?

and the monk responded

Can't you see the two bad bricks?

and the elder monk answered

Yes, I can. But I can also see 998 good bricks

Yes, I built a kludge. I wrote some unforgivably janky
code. And I assure you I would love nothing more than
to delete the whole project and start from scratch.

But I also know that there are 998 good bricks. I know
that it will function properly. And I know that this
application is what is needed by the people who wanted
it. They will might see the two bad bricks, and I
will try to learn from them and have my next project
be perfect. But they will also see 998 good bricks.

So I've decided to be proud of my kludge. At some point,
you will make a kludge too. At some point, we all will.
The important thing is that we don't let two bad bricks
spoil the whole wall.

What is the Joy of Programming?

Austin Hardaway — Wed, 06 Nov 2019 01:43:04 +0000

Ok so a while ago a former student asked me why I decided to become a programmer.
I think what she meant was when did I feel like I was "part of the club" and that's
a valid question and maybe a topic for another time.

But it got my wheels turning about why I like to do what I do?
At first, I thought about the fact that I make a pretty good living doing it.
That doesn't hurt but I enjoyed writing code long before I made a dime off it.

So what then? I couldn't put a finger on it. I knew I liked it but a couldn't say why. Not with any clarity anyway. This frustrated me so I did what every good coder does when they don't
know something. I googled it.

I found plenty of tweets detailing the ups and downs of coding. The desperate pleas to
the compiler. The intense joy when you make progress. And the masochism that draws
someone to enjoy that in their day-to-day.

I wasn't satisfied. Sure maybe that's true. I relate to what they're
saying. I've felt those lows and ridden those highs late into the night, but was
the emotional rollercoaster what I fell in love with? I didn't think so.
Maybe It's ego or a sense of self-exceptionalism but I felt it was in some way
nobler than that.

Surely there was something essential to the act of coding that drew me to it.

I remembered I'd read some books with poignant observations on this topic. And I'd
like to discuss some of them.

Finally, there is the delight of working in such a tractable medium.
The Programmer, like the poet, works only slightly removed from pure
thought-stuff. He builds his castles in the air, from air, creating by
exertion of the imagination. ... The magic of myth and legend has come
true in our time. One types the correct incantation on a keyboard, and
a display screen comes to life, showing things that never were nor
could be.

The Mythical Man-Month, Frederick P. Brooks, Jr.

For a long time, I thought this was the whole truth for me. I loved programming because
I could make something brand new from nothing. I could start with a blank page and
pull the vision in my mind's eye from out of the void.

I might lose some people here, but when I discovered (and then practiced) web dev it
was like magic was real. I was a wizard in a tower studying arcane languages to
manipulate the world around me for profit and pleasure. What could be better than to
live in a world of your own design and be able to reshape at will? Nothing. Case
closed, right?

For a while yes. I thought this was THE answer, and surely it was everyone's answer
on account of how good it felt to me.

Smugly, I sent my friend a picture of that page to share my new lease on life.

She read it. Thought for a bit and she was like...

I was thrust again into an introspective void. My answer wasn't complete. It was
certainly a part of why I enjoyed it so much, but it was missing something. It
was missing a community.

The story of early computer networks has most often been told as a technology
and business story. But like the Internet today, Conference XYZ was not an
engineering experiment as much as an immersive experience... While we were
seeking connection and community we were also helping to build a culture.

A People's History of Computing in the United States, Joy Lisi Rankin

Say what you will about the community of programmers at large, and certainly, there is
plenty to say. Plenty. But it exists. It brings us together on GitHub and Glitch and
Codepen. On Dev.to, on Twiter, and on Medium. On StackOverflow, on message boards, and
at meetups. Surely this question cannot be approached without a nod to the community
of developers that came before me and will exist after me. Making things is great.
Sharing the things you've made is better.

I think it's inherently human to need recognition of that thing you just did. I
think without a feedback loop the drive to get better (not to mention the
ability to) would be lost.

Armed with an expanded idea of what the Joy of this craft is, I called my friend.
Excited I laid out that the thrill of having created a thing + the ability and drive
to share it, I had answered the question I had sought to (several months ago, at this
point). I thought for sure that this would resonate with her. I thought I'd cracked
it.

Annnd,

At this point a gave up. I considered the idea that she didn't like programming. I
considered that maybe I didn't like programming. Maybe no one likes programming.
Or maybe it was folly trying to describe why someone likes anything.

Then, on the recommendation of @jessfraz, I read The Soul of a New Machine (Her
thoughts here)

And out of all of the cool thoughts this read stirs up one really stuck with me.
Kidder invokes the game of pinball as an analogy for the craft of building a
machine.

The bigger game was "pinball."
... "You win one game, you get to play another. You win with this
[project], you get to build the next." Pinball was what counted. ...
"I said, 'I will do this, I want to do it. I recognize from the beginning
that it's gonna be a tough job. I'll have to work hard, and if we do a
good job, we get to do it again.'"

— The Soul of a New Machine, Tracy Kidder

The reason this resonates with me as much as it does is as mysterious as to what
essential part of Software I find so compelling. But something about the idea of
playing a game for no other reward than to get to play again is beautiful in its
simplicity. I program, and I study, and I learn so that when the day is done I
get to do it all again.

It's the act of making, it's the ups and downs, it's the draw of a community, and
it's the simple pleasure of pulling the plunger again. These are what keep me
coming back.

I didn't ask again if this new idea made it her answer, but I suspect not. My
answer is just that. My answer. What's yours?

Udacity Nanodegree Post-Mortem

Austin Hardaway — Mon, 28 Oct 2019 20:24:32 +0000

So I've finished my Front-End Web Developer Nanodegree on Udacity. I have a few thoughts which might be of some interest to anyone thinking about pursuing this program. So here's my two cents

But First Who Am I?

If my thoughts are going to have an relevance to you, you should know a bit about me. I am a Junior Full-Stack Engineer at a prominent telecommunications company. I received a B.S. in Computer Science and a B.S. in Mathematics from the University of Georgia. I've focused on developing for web for the last 6 years. At UGA I was a TA for the Intro to Programming course. So I know this subject matter well, and I've had to think about how best to present programming education.

Disclaimer

I did not pay for the course myself. The company I work for paid for it as part of an initiative for continuing education. I'm not sure if that makes me more or less biased, but either way it's a thing and I won't be addressing the cost of the program.

What You Get

What you get when you enroll in the course really comes in three parts:

Videos and Exercises

The front end course is taught in modules. You could think of them like chapters. Each chapter is broken into sections that have a video that gives a clear explanation of the topic. They are easy to understand and the hosts are experts from within the industry. The videos focus on the fundamentals and best practices around HTML/CSS/JavaScript. They are pretty comprehensive, if a bit rushed in a few sections. The videos do not get into any of your favorite frameworks. There are brief introductions to Ember and Angular, but they are not the focus of this course. Pairing the videos with the odd exercise makes for an engaging platform. This is by a large margin the most valuable part of the course. The videos are higher quality than what would find in most places and it does give you a good basis to work on top of. Unfortunately the rest of the course doesn't hold the same standard.

Projects

Also included in the course are 5 projects that are evaluated as you complete and submit them. They create a guided space to build some web apps such as a Memory game, a Portfolio Website, and a Restaurant Review site. The projects fell a little flat for me. Two of the projects were similar (Memory and Frogger), and the final project felt contrived.

Furthermore, when starter code was made available it was a bit of shit show. Much of the code uses dated standards, uses var vs. const and let, no arrow functions, callbacks instead of Promises or Async/Await, XHR instead of fetch, etc.

Much of the starter code for the projects don't meet guidelines they have for student work. If watching the videos and doing the exercises is taking two steps forward, trying to learn from the starter code is three steps back. Which brings me to the project evaluation. Udacity assigns a mentor to review, comment on, and check your project. They assign a pass/fail style grade and a couple of comments. Seeing the platform for comments, where they highlight a specific line or section and give a comment, got my hopes up. The comments I got were .... odd for the most part. A different person reviews what you submit in each project, and the quality tends to vary a good bit. They try to offer a mix of praise and suggestions in each project. The suggestions I thought missed the mark now and then. And the praise rang a little hollow oftentimes the reviewer chose weird sections. Your mileage may vary here. This part of the course was lack-luster.

The Degree

For a program as expensive as this, a big consideration is what the degree is worth to employeers. Again YMMV here. It shows a bit of domain knowledge in web dev, as well as speaks to your motivation.

As far as my personal stock in a Nanodegree? I would trust that someone who had completed this program could:

Create a responsive HTML/CSS website
Use vanilla JavaScript to handle events and interactivity on the frontend
Write a basic Jasmine test suite
Have a foundation to learn more skills in web dev

Takeaway

This is a good, not great, course to take to get a handle on the basics of Frontend Web Dev. You will learn HTML and some CSS, JS. This course does not prepare you for your first role as a Frontend Engineer. I would say that you'd want to also gain a good depth of knowledge in a popular framework (React or Angular as of Oct '19). Which this course would set you up beautifully to learn.

Anyone else take a Nanodegree? What were your thoughts?

An Intern's Point of view

Austin Hardaway — Thu, 26 Jul 2018 02:56:25 +0000

Before I get too far ahead of myself I think I should say a little about me.
As I am writing this post I am starting the first day of the last week of
my second internship. I have worked for a small(ish) insurance company and I am currently working for a large well-known company.

So armed with a cup of coffee, most of a CS degree, and just shy of 6 months
in the industry I have some observations. YMMV

The coffee is sacred. The coffee is life. Bring down the site, bring down the prod-like environments. DON'T bring down the coffee
Everyone has impostor syndrome. The best cure is to focus on the work.
At the same time the Dunning–Kruger effect exists too and is alive and well. You'll fall into both buckets at times, try to stay out of both.
5 minutes on Google can save you 10 minutes of trying to find out where the hell your mentor/senior/liege/etc. is at the moment
Your senior will feel way less awkward answering questions than you will asking them
That guru that seems to have all the answers was an intern at some point too
You may have the opportunity to Q&A with upper management or executives. Ask questions. Listen to the answers. Remember that no one has any of this figured out and act accordingly.
This will be one of the only moments of the entire experience that you will not have any questions. Come prepared.
Hopefully your organization reminds you that you are here to learn. If not remind yourself.
Your fellow interns will help get you through this experience, be good to them. They'll likely follow suit.
Dress well. The way you are perceived is important, at this point your age works against you.
Productivity is a false god. Work diligently, but inspired thoughts won't always come in neat 25 or 90 minute intervals.
There is a special place in hell for people who take conference calls on speaker in their cubicle.
This may be your first job, but it probably won't be your last. Make some mistakes, learn from them, and have some fun

An Intern's Point of View

Austin Hardaway — Thu, 26 Jul 2018 02:40:55 +0000

Before I get too far ahead of myself I think I should say a little about me.
As I am writing this post I am starting the first day of the last week of
my second internship. I have worked for a small(ish) insurance and I am currently working for a large well-known company.

So armed with a cup of coffee, most of a CS degree, and just shy of 6 months
in the industry I have some observations. YMMV

The coffee is sacred. The coffee is life. Bring down the site, bring down the prod-like environments. DON'T bring down the coffee
Everyone has impostor syndrome. The best cure is to focus on the work.
At the same time the Dunning–Kruger effect exists too and is alive and well. You'll fall into both buckets at times, try to stay out of both.
5 minutes on Google can save you 10 minutes of trying to find out where the hell your mentor/senior/liege/etc. is at the moment
Your senior will feel way less awkward answering questions than you will asking them
That guru that seems to have all the answers was an intern at some point too
You may have the opportunity to Q&A with upper management or executives. Ask questions. Listen to the answers. Remember that no one has any of this figured out and act accordingly.
This will one of the only moments of the entire experience that you will not have any questions. Come prepared.
Hopefully your organization reminds you that you are here to learn. If not remind yourself.
Your fellow interns will help get you through this experience, be good to them. They'll likely follow suit.
Dress well. The way you are perceived is important, at this point your age works against you.
Productivity is a false god. Work diligently, but inspired thoughts won't always come in neat 25 or 90 minute intervals.
There is a special place in hell for people who take conference calls on speaker in their cubicle.
This may be your first job, but it probably won't be your last. Make some mistakes, learn from them, and have some fun