Trying Stuff @samuelgoodwin-blog - Tumblr Blog

Shutting this down

My website went down today for some reason. I can't login to the admin panel at Softlayer to figure out what's going on either. I decided now was a good time to accelerate my plans and launch my new site instead.

So you'll want to stop bothering to check this site, all of the content has been moved to my new site here. The new site is running Ghost, a hip new javascript-based blogging platform, and should work better for my workflow than this tumblr business.

Thank you to everyone who has been reading up to this point or just started reading with this post. I'll look forward to having you at the new location.

Just to be clear:

stop coming here

go to for http://roundwallsoftware.com instead

Trying out some ideas to make location and parsing more clear.

What's Wrong With My App

Last year I launched my first app that wasn't funded by a client or employer. It's called Parts. I never expected it to make millions of dollars, but I had hoped it might at least make enough to pay the rent or some such. In total, it made $44 according to AppViz (a great tool by the way).

After some time being bummed out about this, working on client stuff, and considering attempting other apps, I thought it would be worth considering what was wrong with the app, and why it basically failed.

Parts was originally intended to be "your purchasing todo list". It was supposed to be your assistant when you looked for capacitors and pickups for your guitar customization, or the handlebars and cranks for your next bike build. It would accompany you while visited shops in your travels, and it would make sure you didn't forget where you found that perfect pickguard. Parts was meant for anyone who couldn't (or didn't want to) buy a certain item right at the moment they found it in a shop.

I've spoken with some of the app's users, along with a group of developers and designers whom I respect, to get their opinions on the app--the good, bad, and the ugly. The results were interesting, and I thought I would share them for anyone else working on their first app.

So, here lies my attempt at understanding what sucked about Parts:

Design Problems

You can't rename lists once they've been named. Typos live forever.

Most people didn't realize the app could parse an item's price and an item's name in the same input field.

When editing a part, the keyboard I chose for an item's price didn't allow for decimal values.

Parts should have first-launched with some sample data to help explain the app's abilities. I have been hearing this advice since before the iPhone came out, and yet, for some reason I didn't do it.

Various UI details were not implemented well. This was my first go at an app for iOS 7, and it was designed when there weren't have many iOS 7 apps to use for guidance. And it shows.

The name Parts was a bad choice. Search the app store for "parts" and you'll find at least 1,500 results. Worse, my app isn't even usually in the first 20 in the list.

It was unclear to users why the app wanted to know the user's location. To me, the app's ability to remember where you were when you found something is a big part of what makes it useful. If the user doesn't know why it's happening, then it's not helpful.

Parts made use of iCloud's document sharing to share lists with other people. What people really needed was a way to send plain text or html that could be read by anyone, even without the app.

Technical Problems

Parts was based on UIDocument. I thought this would work well since iCloud's UIDocument syncing is supposed to work better/easier than iCloud's Core Data syncing. This makes it a huge pain to build many useful features, such as showing a list's remaining price before you open a list, or adding cross-list search type features.

The Solution

Sometimes, you need to build an entire thing to really get a feel for how it should be designed. Many of the things I've learned about the problem Parts is trying to solve didn't become clear until I had a mostly-built app, or even after it was published to the App Store.

A big thing I will change is switching to using Core Data rather than UIDocument at the base of the app. The app will lose syncing, but gain the ability to easily have features like "show me items on any list that are closest to my location" or "show me items that cost less than this much because I only have 100$ to spend on hobbies this month". It will also mean I can be more confident that the app won't have problems with losing a user's image data (which happens often right now, sadly).

As a developer, it's easy to think the solution to a problem lies purely in code. However, my website and marketing information about the app were also not awesome. I have enlisted the help of a friend who is much better at this who will be teaching me how to improve this aspect.

Death to Parts, long live codename Manifest. I don't know exactly what it will be called, but it will no longer be called Parts. For now I'll call it Manifest, because that sounds cool at the moment.

On the plus side, an app that does poorly has very few people to disappoint when it tries to become better. I've learned quite a bit from making this app and everything that has happened since then.

Cargo Culting

A cargo cult is any of various native religious cults of a millenarian and messianic character located in the southwestern Pacific islands, holding that spirits will bring large cargoes of modern goods for distribution among its adherents. [1]

After the arrival of the computer and the practice software development, this term was used a slang to refer to a style of programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. [2].

In a modern world of lies and skepticism, we developers have learned to question new ideas, especially when a new idea results in more work. We question ever new idea: TDD, BDD, DDD (basically, any three-letter acronym), patents, new languages, new operation systems, you name it.

Many times, the person sharing this idea is not able to articulate the necessary information you need to decide that their idea is valid. However, just because someone is bad at explaining an idea does not mean they are simply cargo culting it without thought. Before dismissing a new idea as some cargo cult nonsense, perhaps you should stop to consider if there really is some value in there.

Like my new hero Sandi Metz, I'll use a bike-based example.

I ride a fixed gear bike everywhere I go. A fixed gear bike has only one speed (unless I take the bike apart to change it) and the pedals are fixed to the drive train. If the bike is rolling, then the pedals will be moving. No coasting. This is how all bikes worked before the invention if the freewheel and derailure (the part that enables gear-shifting while you roll).

In recent years, this type if bike has become popular with kids on the street. Some might label these kids as “hipsters”. Many of these kids make poor examples of a fixed gear rider as they struggle to ride a bike that doesn't allow coasting. To an outside observer, one might think they keep these bikes as a fashion trend.

I have never thought if myself as a hipster. I'm just a guy trying to make his mom proud and feel welcome in his surroundings. For some reason, people are quick to call me a “hipster” and define my world and who I am by assuming I ride a certain bike thanks to cargo culting. I chose to ride a fixed gear bike for utilitarian reasons. They just maybe have never heard or don't count those reasons as valid.

Someone who spent time considering the choice would find that there are several utilitarian advantages it such a bike.

No gear changing means no maintaining the gear-changing mechanism.

No coasting means better control over you speed, especially in wet weather conditions that would negatively affect most brakes.

Less parts means I can service most if my bike without help.

When I first considered trying a fixed gear bike, I thought about the flack I might catch and the “hipster” labeling I might receive. Fortunately, I did not allow these opinions to keep me from trying something I now enjoy very much. I thought for myself, did my research and then made a choice.

The same should be said for popular programming practices as well. TDD, functional programming, whatever new language or framework pops up, and anything else you've heard of should be properly researched before you dismiss it or embrace it. How can you make an informed decision without first being informed?

By proper research, I definitely don't mean just asking your friends about it or reading some blog post that rants about how awful it is. You can find someone who thinks almost any idea in programming is an awful one, often because of some bad experience they had once. Don't take their word for it, find out real information so you can make real decisions.

[1] http://dictionary.reference.com/browse/cargo+cult [2] http://en.wikipedia.org/wiki/Cargo_cult_programming

Coding Exercises for Prospective Hires Are Stupid

Earlier on App.net/Facebook I posted this:

"Also, asking potential hires to build apps as part of the hiring process is stupid."

Perhaps short-text social media is not enough to properly elaborate my thought. Here's a better version:

If you want to see professional work from a developer, pay them professional rates. That's how capitalism works and that is the world we live in.

I fully understand and sympathize with the goals of someone hiring a developer. They want to know that the developer they're talking to can do the work. An excellent way to do that is to see some of their existing work. Totally valid request.

Some developers have work already visible. They have public projects in places like GitHub and BitBucket. Problem solved, browse away and enjoy!

But what happens when they don't have code publicly available (or not code in the specific use you're looking for)? Should we ask them to produce some code you want to see? Yes. Should we ask ask them to do this for free? Definitely not. Here is where I have a problem with these code assignments hiring companies ask developers to do. A human being has a limited time on this earth. A large amount of that time is spent sleeping. Another large chunk is taken out working (because we live in capitalist countries where not working means not eating mostly). What's left is that special sacred time where a developer might spend time with their families or read a good book or maybe even sleep more.

When a company asks a developer to write code for free as part of the hiring process, they're asking that developer to give up this precious time for an arbitrary exercise.

In the past, I have interviewed with companies who have found some good solutions to this. Some found what they were looking for on GitHub and my blog. Some paid people for a week or even a day of work where they could better evaluate someone. This is my favorite solution. Others will hire someone on a probationary period, like a couple months.

Once a company is paying a developer for their time, whatever tests they want to do is fine. They don't need to be doing work on the company's product, that's up to the company.

Finding new developers is hard. Hiring people in any field is fairly difficult. Hard problems are what we solve for fun. Let's find better solutions than asking a peer to do speculative work.

2014: The Year I Wrote Better

Getting Better

Those of you who already read my blog know that I'm not the best writer. You're likely either reading this because you're either related to me or the technical information has helped you. Thank you for reading! This year is going to be better. More content, better writing, you're in for a treat. The nice part about not being very good at anything is that it's much easier to go from pretty-crap to good than it is to get from great to excellent, so this should be easy!

Strategy

Here's the plot:

Reduce friction to post.

Reserve more time to post.

Find a good editor (the person, not the application).

In theory, these things will lead to higher frequency and better posts. I only wrote 15 blog posts in 2013. Some of which are maybe 2-minute reads. That's no way to improve and not nearly enough information for people who are looking for it. If you have any other strategies for improvement, I'm happy to hear them!

Reduce friction to post.

Right now I write notes about the posts I write on my phone or computer wherever I am. Then at home, I type my blog posts on my computer using vim or BBEdit or whatever editor I feel like writing in that day. Then the post is copy/pasted to GitHub's gist system to easily share it with a few of my friends who make comments on readability and grammar mistakes. Once the post has been looked over by everyone, it gets copy/pasted into Tumblr. This is a pretty silly process that is rife with friction. In theory this can be reduced by streamlining the system. There are way better blogging solutions for people who want to do more than post a photo or link to an article. To actually write articles, something more like Wordpress or Ghost or something I haven't heard of is better.

Reserve more time to post.

This one's pretty straightforward. If you specifically block out time to write, you'll actually write. It doesn't need to be entire days at a time, just some time on a regular basis. Same strategy developers use to make sure they make consistent progress on their own apps. I'm going to aim for 30 minutes per day, but some more for the this first week to get things started.

Find a good editor.

I've been told by many people that this one will help quite a bit. I know a few people who might be willing to do it. If you want to be my editor, feel free to let me know!

Intelligence

Words like "intelligent" and "stupid" and "smart" and "genius" get thrown around quite a lot these days. I think they're all mostly bullshit and distract from the real issues.

In software, we often run into people who lack the depth of knowledge and experience in the various fields necessary to make apps. Many of us lack business and marketing experience, some of us lack experience in Object Oriented Programming or Functional Programming, many of us lack experience in a specific platform or language. Maybe now we use that new language or platform for work.

Now, someone who does have experience in these fields (or at least thinks they do) might think "man, these other people are such idiots. I'm the most intelligent person here" or "they must be stupid because they don't do xyz!" and that's simply not the case.

To say someone is stupid or an idiot or lack intelligence is reductive and definitely not helpful. In my limited time trying to teach people how to program better, I've run into many people who are extremely smart. Probably smarter than me (though I think comparisons like that are also unhelpful). The reason I'm teaching them isn't because I'm smarter than them, it's because I have more experience than them in the field I'm teaching them about.

One of my clients recently hired me to come in and talk to their team about using Core Data in iPhone apps. These are all smart young people who make value in the form of software on a daily basis. They just haven't ever used Core Data for any of that software yet, so they wanted to ask questions and get an explanation. They wanted to benefit from my experience so that they could more quickly get back to delivering value.

So if you're one of those people who lack experience, don't worry about it. Un-isolate yourself, go out and find the people who can help you and absorb as much of their experience as you can. If anyone tries to put you down, you tell them to take it up with me.

And if you're the jerk calling everyone else idiots simply because they don't have a depth of experience in the specific topic you're trying to discuss or use, then shut up. Nobody cares if you're right when nobody wants to talk to you or work with you anymore. Nobody listens when you call them an idiot. You probably won't even listen to me because I called you a jerk.

#define

When to use #define:

When you're declaring macros like in Apple's:

`#define UI_USER_INTERFACE_IDIOM() ([[UIDevice currentDevice] respondsToSelector:@selector(userInterfaceIdiom)] ? [[UIDevice currentDevice] userInterfaceIdiom] : UIUserInterfaceIdiomPhone)

I'm actually not even sure why this wasn't made as a function like NSLog instead of a macro.

When not to use #define:

When you're declaring constants. Constants should look like:

NSString *const RWSSomeConstantName = @"theValueDoesn'tUsuallyMatter"; const NSInteger RWSIntegerConstant = 3;

Why go through this effort to type extra letters?

Constants declared using #define don't show up in tools like the debugger. #define is raw text substitution, constants are symbols to your debugger, like class names.

#define won't warn you if you use #define in some other file and change the value of your constant accidentally.

Duck Types and Objective-C

I just finished the book, Practical Object Oriented Design in Ruby. I haven't been paid to write Ruby code in years and I still found the book incredibly useful. Sandy Metz writes excellent explanations for many things I have felt about code I have seen while working on projects.

In the last chapter, Sandy discusses how to write effective tests. She walks through creating tests to document "duck types" by writing tests that make use of assert_responds_to. I think with Objective-C these tests are unnecessary for the most part. In Objective-C we can formalize these "duck types" with Protocols. This way the compiler will tells us when our object fail to implement the interface other objects expect. You know, assuming we don't ignore the warnings coming from the compiler.

A "duck type" gets is name from the phrase, "If it looks like a duck and quacks like a duck, it must be a duck". The idea is that you can write code that doesn't care what something actually is, so long as it responds to the right messages. This makes for loose coupling between objects because each object doesn't have to know exactly what type of object it is working with, simply that it will respond to a certain set of messages.

In theory, you could just use retro Objective-C tactics and declare these "duck types" as id instead of id<RWSTypeProtocol>. This is basically what Ruby does, objects technically have a type, but since you cannot specify the expected type of inputs to Ruby methods, there's nothing to let you know when the wrong kind of object has been put in the wrong place.

When we make use of the constructs provided to us by the language in Objective-C, we can eliminate the need to write tests that assert that our objects adhere to the "duck types" we expect them to. This is what protocols are for. As long as we make use of them, create them, use objects that adhere to them, and pay attention to the compiler's warnings, we can write loosely coupled code that doesn't need to be verified with tests. Who doesn't like writing less tests? Certainly not this guy.

This is why you shouldn't arbitrarily typecast things in your Objective-C code. Typecasting tells the compiler, "shut up, I know what I'm doing!". See you know what you're doing right now, but you from 6-months-from-now might not. Certainly the new guy who now works on your project has no clue what you were doing.

In conclusion: - Embrace the language you're writing. - Avoid typecasting - Make use of its advantages and avoid its disadvantages - Learn from the patterns and styles from other languages, but consider how they might not work exactly the same in the language you're currently writing.

Capacity

I try to be extra careful to consider my capacity before agreeing to do something for or with someone (or even for myself). Mis-judging capacity seems to often be the cause of frustration and failure. I think now I finally have the capacity to do something cool that isn't for a client.

I think about capacity in a few different ways.

Skill

Producing anything, apps, music, books, needs skill. More skill and experience in theory allows a person to produce in less time. It certainly can allow a person to produce higher quality things.

Social

Some of us have a limited capacity for being around other people. Once this is depleted, we need to have some alone time to recharge. The internet makes this easier by allowing us more time to interact with others because it drains this capacity more slowly.

Financial

Producing things also cost money. Supplies cost money, time costs money, travel and food cost money. It costs even more when you need to bring in other people to help. I think the reason many projects fail is because the people involved misjudge their financial capacity and were unable to get production far enough along to start making more. Many developers take on client work to help increase their financial capacity, but that comes at the cost of capacity for time, which often keeps them from finishing production as well.

For the past 2 years, I have been focused on my financial capacity. I needed money to move to Amsterdam and then suddenly needed money to pay off my student loans. I could not continue to pay for my student loans on into my 30's or 40's, it had to be paid now. Fortunately that will all be over this week. I'll be a free man with a new-found financial capacity.

Time

Human beings have a finite amount of time before we drop. Some of that time we spend sleeping, some we spend floundering about struggling to learn to walk and eat and talk, some we maybe spend in an old folks home trying to remember our names. In between we have a chance to do useful. There are only so many hours in a day and some are spent sleeping. Without enough un-allocated time, no one can produce anything cool.

I've also been concerned with my capacity for time. I frequently ask myself, "Can I agree to help with this event or meet this friend given all the things I have already committed to this week?" or, "Can I build the software my clients want in the time they need me to?"

Patience

Making things is hard. Increasing any kind of capacity needs a certain capacity for patience, including increasing patience. Capacity for patience also comes in handy during the hard slog portions of production.

Let's Do This

I think now I finally have the capacity to do something new. I want to find other developers who also have enough capacity available and build something awesome. I know so many developers who have excellent skills and knowledge, high levels of patience, but often little time capacity. I'm not the desperate guy at the bar praying that he won't be alone the rest of his life, mind you. This is just to say that I am ready, willing, and able to take up the arms and face software problems bigger than one person.

How to get started with remote pairing quickly

Remote Pair Programming is a thing now that people do. Basically, it enables you to learn from and work with anyone anywhere, ever. You can do that thing we love to do (write code) with a diverse range of people.

So let's say you've decided you like this idea of getting out of the bubble of programmers you know well and you can't to go see how the rest of the world lives. I'll show you how to setup your Mac to do just that:

1. Install the tools you'll need.

You'll need a few things here, easiest way to install them all is with Homebrew.

brew install tmux

Tmux lets multiple people use the same terminal session. This is way faster than relying on any screen sharing application and works even on less-than-epic internet. It also lets you do a bunch of fancy things (4 minute video) to manage multiple windows and split-screens in your terminal session.

brew install vim

Technically your OS X install comes with this already, but the version we get is not the latest version of Vim. They have fixed bugs and made improvements in performance and such since the version that ships on OS X. Also, you might find that some plugin decide to use just won't work on the older version. Might as well install it while we're here.

You'll also want to grab a copy of ngrok. This is a convenient way to give people access to your laptop without needing to do all kinds of router configurations (which you maybe can't do if you're forced to use your ISP's router, bleh). It also gives you some monitoring abilities, lets you track usage and keep up with who is using the connection.

2. Let your partner onto your system.

Now I personally wouldn't even give my password to my wife (if I had one), so here we'll use ssh keys. Tell your pairing partner to send you their public key. If they use github already, you can find their keys by adding the extension ".keys" onto their profile url. For example, you can turn my profile url https://github.com/sgoodwin into https://github.com/sgoodwin.keys and see all of the public keys I've added. If they don't have one already, github provides excellent documentation to explain how.

Once you have their key, you'll want to add it to your ~/ssh/authorized_keys file. If you don't already have this file, feel free to create it. You'll want to add an entry (just a new line) in the file that looks something like this:

command="tmux attach" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3iQgxhX0Ozb6oy9eORGIY3HowlDtUfKpWNJCwiU2F1aRA9alsxeSvjJpOxqKip3Z7//ynPUK151r/ZU9aBmv43n3RITSUQqM1BAYoXPTCrQeehBJIzEE4wXFm8NUkSwTiF7xHdCDo7rnluz58qUWDpHxcb/XwZFt17zGO/PPuJcFkuy79la37xvol2fb9No2TON54ZBbx8Xi2IzEbxbWTmMc6K+vwwxZPIAQz5EL3vBRrtyT8RHjhF3G5Z1KmD6YkX9BaYnUbX+3WYVhzo19QRgiRgE9I5IP6KNSKJuxKBb4SaYdPJbn/cUPgvZmMj1oaoTUW2236FXglIjAaDoEx [email protected]

The first bit there supplies a terminal command which should be executed as soon as they login. I chose the command "tmux attach" which puts them directly into my tmux session so we can get started. Whatever command you put here, the ssh connection will close as soon as the command finishes. If you put ls for example, it would print the contents of your home directory and then close the ssh connection. Now when they ssh into your machine, they'll be tossed right into your terminal session and you two can get to coding.

Once ssh is configured, turn on ngrok and let them in with the command:

./ngrok -authtoken <YOUR AUTH TOKEN GOES HERE> -proto=tcp 22

This will open the gates to your machine and display the url your partner can use to find your machine with ssh. Once they do get ssh to connect, you'll be looking at the exact same terminal session and you can get the party started.

3. Connect with some audio

Now that you can both type, it's helpful if you can both speak. Skype does an ok job with this (audio only, video and screen sharing are slow and mostly bad). You could also use something like FaceTime Audio which has excellent audio quality in my experience. Whatever you two want to use is cool. Use your cell phones even.

Some warnings

I don't know these Ngrok people very well, for all I know they're recording all of my traffic to report to the NSA. Probably shouldn't use it for your terrorist plots or for coding sessions where security of the code you're looking at is super important. You're working over ssh, so your work is encrypted, but you know, sometimes you need to be paranoid.

If you start to feel uncomfortable about the person you're going to pair with or even during the pairing session, pull the plug (just quit ngrok) and delete their key.

Even with these caveats, there are some advantages to setting things up this way:

No need to manage your configs on a different system. I'm not a fan of maintaining configurations on more than one machine, so this is a big win for me.

Dtrace. Another option you have is to share some server and work there instead of your own machine, but linux machines don't get dtrace, your Mac does though!

It will take you maybe 30 minutes to set this up. Your dev environment is already setup on your computer, all you have to add is the bits to share it with someone.

Now that you're equipped to pair with people, you can go here to find more info about pairing and places you can go to find potential pairing partners. This is one of the ways we can get around not having enough more-senior developers near us. Go learn things!

#pairing #remote pairing #tmux #vim #ngrok

Thank You

The annual 360iDev conference just happened. I got to go, I enjoyed it very much. This time I wasn't just an attendee, I joined the ranks of the great 360 speakers before me and attempted to do them proud. Soon my talk will be online and any of you who missed it can watch it. People I didn't know told me they liked the talk. I even received a very nice email from a stranger thanking me for sharing my "success story". It made me feel special.

Twitter doesn't have enough characters to thank the necessary people, so here we go:

Mike Lee (@bmf): Thank you for your training.

Judy Chen (@judychen): Thank you for being there.

Collin Donnell (@collindonnell): Thank you for being there.

Matt Henderson (@ghostM): Thank you for being there.

Joe Keeley (@joekeeley): Thank you for the present and for being there.

John Wilker (@jwilker): Thank you for giving me a shot.

Nicole Wilker (@nwilker): Thank you for giving me a shot.

George Woodliff-Stanley (@gmws82): Thank you for being there.

Paul Darcey (@pauldarcey): Thank you for being there.

Even this doesn't really express how thankful I am for your help. I would not have been able to do it without you.

Make Git Friendlier: status

Since I couldn't sleep tonight, I watched a presentation by this guy Zach Holman who works for GitHub.

One tip he shares makes the output from git status much friendlier and I thought I'd share it so you don't have to watch an hour of talking to find out about it.

Instead of:

git status

try typing:

git status -sb

I went so far as to add this to my ~/.zshrc file:

alias stat='git status -sb'

Basically, it makes the output from git go from something like this:

sgoodwin:Parts/ (master*) $ git status [4:13:13]

On branch master

Changes not staged for commit:

(use "git add ..." to update what will be committed)

(use "git checkout -- ..." to discard changes in working directory)

modified: Parts/Parts-Info.plist

modified: Parts/RWSAppDelegate.m

modified: Parts/RWSListsStore.m

modified: Parts/RWSListsViewController.h

modified: Parts/RWSListsViewController.m

no changes added to commit (use "git add" and/or "git commit -a")

to something more like this:

sgoodwin:Parts/ (master*) $ stat [4:13:40]

master

M Parts/Parts-Info.plist

M Parts/RWSAppDelegate.m

M Parts/RWSListsStore.m

M Parts/RWSListsViewController.h

M Parts/RWSListsViewController.m

which is so much nicer because I don't need all that other junk (also it's in color if you have that turned on).

Happy coding!

#git #code #protip

Community

Being a part of Appsterdam and trying again to run my own business has made me think differently about community.

We grew up as nerds in school and learned to expect people would think we're lame for the things we loved. We kept the things we loved to ourselves and looked for the few people on Earth who also loved those things as much as we did so we could share with them.

Community is really not just about sharing with other people who are as deep into what you love. It's also about opening up what you love to teach it and make it accessible to people who are interested.

Community is about helping and getting help from those around you. With one hand we each should reach out for help and with the other we should reach back to help those behind us. Together, we all pull each other up and the community thrives.

The fact that the Objective-C community is still growing at a crazy rate and is already huge does not mean our community can't be the one some of us know from before the iPhone. There's just more of us to help each other out now, this is a good thing. We should all be reaching out so we can collectively lift the whole community up.

Manually set location on an item?

#MadeWithPaper

Think of the Children

When I was in college for electrical engineering, I learned to program objective-C for the Mac and that has now become my full-time job instead of engineering. The primary reason for pursuing a life of software development instead of engineering was the community. The developers I read about like Mike Lee, Daniel Jalkut, Gus Mueller, and so on made me so very excited to write software for a living. When I had the chance to meet them in person, along with other developers, I was even more excited. It was a community, a group of people who gave a shit about each other.

When you choose to take shortcuts in your freelance projects, consider the effect on the community. When you whip out that singleton because it's quick and easy (and we all know it's a bad idea), think of the community. Think of the other developer who has to add features and fix bugs on the project once you're done. That poor guy (or gal) has children to feed, expenses to pay, and needs to take this project to make the money to take care of that. They have to add features onto that project full of your shortcuts. They have to pay the technical debt you acquired to get the job done. Like all clients, the client is hassling them to get it done as quickly as possible for as little money as possible.

Your shortcuts have made life harder for that person. That person can't afford to tell the client it can't be done because they have bills to pay. The client won't listen when that person says the app needs to be re-written because of the mess you left bend.

Think of the children when you choose to take those quick, easy, delicious shortcuts. The children the next guy has to feed by adding features and fixing bugs in your code. Don't just try to write better code for yourself, do it for the community. Sure, no one is perfect, but do your best to learn how to write things so that you can be nice to your fellow developers.

Failure

It is becoming popular, especially in American tech culture, to encourage failure as a natural part of learning and a key to success. Humans fail in many casual ways to learn basically anything, even basic skills like walking. Failure in software is often expected on a very minor level. Maybe I'll release this software and it will have a bug in it. Maybe I won't get that job at that big tech company I applied for. The real failure in software is when all the work you have done falls apart so badly, largely from your own mistakes, that you lose everything you have spent years working for and have to beg for a place to sleep with your tail between your legs barely able to afford the shirt on your back. It's the kind of failure they joked about in engineering school when discussing friends who were artists and musicians and maybe even dropped out of school. We felt safe studying engineering, a profession so obviously useful that surely we will all have jobs and be paid well. We were wrong. Horribly wrong. If it wasn't for software like Rails and iOS and my fortune in having a skill to work with them, I would have been unemployed indefinitely after college. Many of my friends spent *years* living with their parents maybe working at the local grocery store or mall. They had engineering degrees from a serious school with way better GPAs and qualifications than I did. The truth is everyone who is working a job they enjoy and getting paid, a job they actually wanted to work, is incredibly lucky. I have spent most of my life reaching out further than I should, often a breath away from failure. The day I received my rejection letter from MIT, I locked myself in my room and didn't sleep. I refused to get out of bed in the morning, I just wanted to be left alone to cry. My mother (a decently smaller person than me) literally dragged me out of bed and would have slapped me if necessary to get me to put on clothes and go to school. She believed in me when I no longer did and refused to allow me to quit. I had people like her who saw something in me and helped me to continue and do the awesome things I have been able to do. Without them I would be the failure I'm afraid of. I was incredibly lucky to have a job before I graduated working on Rails and iOS projects. I was incredibly lucky that I didn't fall flat on my face when I decided to leave that job with no plans and no savings. I was lucky to get a well-paying job in NYC. I was lucky to be in a position to even consider leaving that job to go to Amsterdam. I had no plan when I got to Amsterdam, I just foolishly thought it would magically work out. Turns out it didn't work out completely. I neglected important details like having any savings, paying off my college loans (which are expensive because I failed to keep my scholarships), and the business development necessary to keep contract work coming. Now true complete failure is entirely a possibility. Not just a failed feature or a failed project. A failed, broken, person. Fortunately for me, my lifetime of reaching further than I should has left behind dear friends and family members who would accept that broken shell of a man, desperate and hungry, back from Europe, and they would make sure Blynken and I weren't out on the street. Even in absolute failure I am incredibly lucky to have these people. This is what keeps me up at night.

Trending Blogs

Recently Viewed Blogs

Trying Stuff