South By…A First Timers Perspective

Last weekend I got to attend SXSW for the Interactive portion of the conference/festival (SXSWi).  It was also my first time staying at an AirBnB.  I can say both experiences were very memorable and awesome.

Every programmer/software engineer/coder/developer should go to South By at least once because it is truly a unique experience.  I haven’t been to many conferences but this one straddles the line very well between party/festival and conference.  There are probably 100 sessions a day, including lectures, panels, meetups, hackathons, Q&A and competitions.  For the interactive portion, there is a healthy mix of developers, graphic designers, UX people and app developers.  There are so many sessions that looking at the schedule feels like drinking from a fire hose.  Since there are so many sessions, you are free to choose your own adventure.  Don’t like the talk you are at, leave for another session.  Met some cool people after a talk, join them for a drink or at their next session!  There will be many sessions that you will want to attend that are going on concurrently.  Most venues are within a 10 minute walk of the Austin Convention Center which makes it very walkable and easy to get around.

Everyone from the speakers to the volunteers to the organizers, preach about the “hallway magic” that occurs at South By.  They encourage you to leave your friends and try to meet new people.  They encourage you to note the sessions you’d like to attend but to embrace the serendipity of South By – you never know who you will meet and when you will meet them.  At the start of the festival I was a bit timid in meeting people, but by the last day I was arriving at the convention center with nothing to do for 2 hours and just heading to a phone/laptop recharge lounge to chat with random people.  I was even going to the parties at night by myself (first time going to the bar by myself) and trying to meet as many new people as I could.

SXSW is really what you make of it.  You can party from 11am to 1am every day.  Or you can attend sessions from 9am – 6pm and not party at all.  You could even arrive without a official badge and enjoy all the free stuff and network.

My favourite sessions I attended:

• Hackathon for Social Good – got to meet some cool people and do some work!
• Elon Musk Keynote – loved his no bullshit attitude, his humility and bravery
• 100 Mistakes from contributor to CEO – Meebo cofounder Elaine Wherry – so engaging and learned a ton!
• Next Gen Entertainment Entrepreneurs – Vhx.tv, slated.com, blcklst.com – Panel discussion on breaking through Hollywoods barriers

I know I did it right because I wouldn’t really change anything about my trip.  I had a great time.  Now for a list of tips:

1. Don’t hang out with your friends – put yourself in a situation where you have to meet new people
2. Know that you can’t get to everything and be okay with that
3. Drink lots of water because you will be consuming more alcohol than you think
4. For most parties RSVP doesn’t get you anything – I used rsvpster but I didn’t use it once to get in….I still don’t get why they make you rsvp. (I still will probably RSVP next year just in case)
5. You will be disappointed by how bad (or not what you expected) some sessions are and surprised by how good some other ones are – be flexible with your schedule

See you in SXSW next year!

Advertisement

Every Software Engineer Needs Rules To Code By

As software engineers, we make lots of decisions on a daily basis.  It is definitely a skill that you can develop and improve upon.  From my experience, you get much more practice at this skill in a startup.  You get to build a lot of new software with not much guidance.  Many times you need to pick the technology/library/etc before you even start developing a solution.  I feel my decision making has improved tremendously in the year that I have worked for a start-up.  There are many ways you can improve your decision making ability.  One helpful mechanism for decision making, is having a set of rules that you live (design/code/test/implement) by.

Every software engineer should have a set of rules they live by.  Most developers have 0 rules when they finish university and start their first job.  The main reason for this is that we “gather” new rules through experience of screwing things up.  And I am referring to those bugs or time wasters that really cost you or your company time and money.  In school, you usually aren’t working on large pieces of software or mission critical features.  You also don’t own code for a substantial period of time usually.  So you don’t carry the burden of bad code or see the result of bad decisions.

The typical scenario goes something like:

1. Create and release some feature
2. Something very bad happens. (e.g. bug costing thousands/millions, spend 3 days debugging a problem, spend 3 extra days refactoring, etc)
3. You fix it.
4. You think to yourself, how do I not let this happen again.

There are a ton of other ways it happens, but from personal experience this is the most common scenario.  So people amass rules depending on the experiences they have had.  Very rarely do we learn from someone else’s mistakes.  One of my favourite quotes:

“Smart people learn from their own mistakes.  Smarter people learn from other peoples mistake.”

I think these rules are important to have because they help prevent mistakes and make decisions easier.  The less questions you have to ask yourself, the less decision fatigue you will experience.  Leave your decision making power to the more difficult decisions.

Without further adieu, some rules off the top of my head.

1. No code change should go untested.  No matter how small or trivial.  I don’t mean unit test every single line of code, but see it work.  Too many times I decided not test something because it was too small or trivial.  Then subsequently it broke in testing or production and I looked really dumb for not performing a basic test.  I have seen this happen to other engineers as well.  It usually is painfully obvious that no testing was done.
2. Don’t try to predict the future.  I have spent too much time thinking of what might come next when developing certain features.  I have been burned implementing extra features (feature creep) and then throwing it all away anyway because the system was going to be used in the way I foresaw.  This is especially true for marketing oriented organizations as they tend to change their mind a lot.
3. When you can’t decide, just pick a route and go from there.  I used to spend a lot of time comparing 2 different approaches to a problem.  Often there wasn’t an obvious winner and I would spend too much time splitting hairs.  Now, when I realize that I am doing this, I pick a solution and go from there.
4. Have more than one solution.  I read somewhere that having only one idea is dangerous.  Too many times I have implemented a feature only to have a co-worker suggest a different (more logical) approach which had me scrap half my code.  Now I try to think of these before I start designing.
5. Behave as if things will go wrong.  I know this is on the “glass half-empty” side, but this sort of thinking has helped me.  How many times have you finished writing a piece of code and went to run/test it and it worked first try?  You will start to ask yourself valuable questions such as; how can this break? If it breaks, how will I know?  how will I debug it?

These are a few that I have learned and wanted to share.  I am still early in my career and I am sure this list will grow!