I was motivated to write this blog because two things. First was Kyle Daigle, from Github, and second ShipIt Saturday event at LaunchAcadmey.
Kyle was a guest speaker at Launch this week. His talk was not
technical but everything else you think of in terms of ideal job
situation, work, environment, culture, and ultimately what you want. To
figure out what was important to me I began to think of all the
companies that I admire, or want to be part of.
My 3 requirements are
90 - 100% Pair Programming
Time for Open Source contribution or to learn, anything programming related
Agile Practices + TDD
Throughout my experience at Launch, I learned that 2 set of eyes are
better than one, at mostly everything. It was much easier to catch spelling errors,
make design decisions, determine user requirements, and trouble shooting. The only thing that I prefer doing solo is if we both don’t have a clue and need to just learn by trying. I wouldn’t mind banging on the keyboard for 15 or 20 minutes and coming back with a solution. However, overall I find it that most errors have been encountered either by myself or my partner and it is much easier to learn by teaching my partner.
My second requirement is because I want it to have the spirit of the
Ruby community. One thing I have learned in the past 3 months is how
willing ruby on rails programmers are to helping others out. I want to
give back as much as I can, and I want my company to want to give back
to the community for making me great and awesome. Also, it’s a great way
to market the company. thoughtbot is a great example, factorygirl,
shoulda, etc.
Lastly, I’m a heavy believer of the minimum viable product populared by
the lean startup movement. I think it is important to be able to bring
a functional product as quickly as possible to market for feedback and
repeat the cycle. I think agile practices is very close to this idea.
Instead of guessing what the customer wants, by showing the customer
piece by piece. This way as a developer I get immediate feedback of
whether the product was what the customer had in mind, or figure out
exactly what the customer had in mind, and go back to the keyboard. I
included Test Driven Development, because I don’t believe that one can
practice agile without the other. As programmers we can’t change or add code
with confidence if we don’t know what this change is going to do to our
program. This will ultimately slow down production and lead to mediocre code. Not very
agile.
My next motivator for finding the right environment was Ship It saturday. The event was that you work on anything you’d like and be able to ship it to production(heroku) by the end of the day. Working under that time constraint was no joke. Being under that pressure to get something out was quite intense. Espeically calling everyone out that they needed to be done in order to upload their app to my site called ShipIt Saturday. The first half of the way wasn’t too intense. I was managing my time well following the red, green, refactor. The last 3 hours was quite brutal. I was stuck with the idea that it would be easier to implement a voting gem that was inactive for over a year. I ended up trying to figure out how it worked for 2 hours and talked to some people there and went on to write my own voting system. It was pretty much the most intense hour I had, in my programming career. I was sweating, anxious at the thought I was going to disappoint those who were going to display their app on my site. However, trying to keep a level head, I focused on my breathing and began to work. My final implementation of my voting system wasn’t 100% tested, but I tested the core functionality of it. Got the app up on heroku for live deployment. Yeah, I wouldn’t want to repeat that experience again. Although, I tested the core functionality that people are able to vote. I didn’t test to check that the position changed based on the amount of votes an project had.
If I had more time, I would have covered 100% and would have caught that
projects position weren’t changing. I think high stress and deadlines
environments produce may produce products, but not so maintainable code.
I want to work at place where quality of the code matters more so than
meeting deadlines. Of course there are exceptions and circumstances
where dealines are important. But hopefully the company is working with
customers who understand quality over speed.
*Thought: It takes time to be a great developer. If you
realize that you’re not going to be great in the next day, week, or month.
The ride will be much enjoyable.
John