akrish

I just finished my summer internship at Tellme yesterday, and it was an amazing experience. Not only did I have a really fun time working there, but I definitely learned a lot and I also got to see the infrastructure of a moderately sized company. I was a applications developer intern, so I ended up doing a lot of coding, but everything I did there was very different from any of the coding projects I’ve worked on for fun or for school. A lot of the differences were essential to running the company, but some of them made things run a lot slower. Most of them however, were really good programming practices that I’m beginning to pick up and notice in my own coding. Here’s some of the things that I learned from my projects, the employees, and of course, my fellow interns:

1. Consistent Coding Style For the most part, code is pretty hard to read. You probably know that if you’ve ever wanted to add to something you wrote a couple of months ago, and then figured it’d be easier for you to start from scratch than to decipher your code and augment it. When working on bigger projects though, it’s a huge waste of time to start over, so you need to make your code as readable as possible. It’s even more important on team projects when other people will be reading your code and using it or adding to it. On these projects, it’s essential to have a consistent and defined coding style that’s used by all members of the team.

One of my projects at Tellme involved abstracting some preexisting code, so naturally I had to read through all of it. There was one file, that was about 2500 lines long, incredibly dense, and very unintelligible.

It took me about a two full days to go through this one file and figure out what was going on, and this was largely because the coding style sucked. Anyway to make a long story short, having a consistent coding style really adds to the productivity of a team, especially on large projects.

2. If it’s not tested, it’s broken I was amazed at the level of testing that went on at Tellme. Even things like content changes to their corporate website would be reviewed by a pair of developers and then by a QA engineer. It was a standard practice to review these minor changes on four or five different browsers, which I found to be a bit excessive, but also very thorough. It was a marked difference from the level of testing that goes into my own projects. On my projects, I used to just test until it works a couple of times, but after seeing how production-grade software is tested, I’ve started to write testing suites and actually test my projects.

3. Production Quality As I spent time at Tellme working on their projects, I realized that everything I’ve ever coded hasn’t been suitable for production at all. In fact a lot of what I do is take an idea to proof of concept, and then drop it. I never spend time on exception handling, error checking, parameter validation, documentation, or even optimization, but all of these are essential to making software actually usable. It’s interesting to see that programmers end up spending most of their time on these things, rather than the things that I end up doing. They code a lot, but very few of them are actually designing new things. A lot of the time they work on making things robust, and actually usable.

4. Bug Fixing Most of working on a development team is spent fixing bugs. It’s something I don’t really look forward to when I think about getting a job. I’d much rather be actually working on something new and innovative than fixing bugs for a career. Pretty much the first half of my internship was fixing bugs on Tellme’s website, and that was actually really boring. Granted it was important and needed to be done, but the work wasn’t very intellectually stimulating at all. I guess it goes with making production quality software, but it’s pretty monotonous to be fixing bugs all day.

Speaking of bug fixes, the other interesting thing I noticed was that Tellme would release software with bugs in it all of the time. Apparently it’s a pretty common practice for companies to do this so that they can meet their deadlines. It makes sense to me that they need to release software by a given date, so they purposely don’t address some bugs, but it’s also very odd for me, because whenever I see a bug in my software, I immediately fix it. I guess that’s one of the differences between a side project that you work on in your free time, and a project that you work on for a company.

5. Programming Overhead This is one of the things that makes me not really want to work for anything but a startup, but the developers at Tellme are actually only writing code for maybe 25% of the time they’re working. So much time is spent communicating, maintaining servers, interacting with huge code bases, and all sorts of other stuff, that they don’t actually spend that much time coding. A lot of what they do is necessary: people need to communicate on team projects, servers need to be maintained, and when you have a lot of code, you need to have some way to store it (i.e. version control systems like csv or svn). These just aren’t thing’s I really want to be doing for a career, at least not right now. I want to spend my time designing innovative technologies, and writing really cool software, rather than on maintenance. Seeing this at Tellme (which is already a pretty small company) made me really want to work for a start-up, where I wouldn’t have to waste some much time on overhead.

There definitely are more things, which is why I’ve titled this part 1, but I’m having some serious writer’s block right now, so I’ll get to the other stuff later. I also plan to write about the more general lessons (not related to programming) that I learned at Tellme. A lot of the things I didn’t like, aren’t really specific to Tellme, but more are causes of working at a company with a lot of people. These are all things that are essential to company infrastructure, but annoying to deal with as a developer. I’m sure I’ll get used to all of these things when I actually get a job, but as a student, they’re things that make me not really want to get a real job. Overall though, I really enjoyed my time at Tellme, and it was an amazing learning experience. I highly recommend getting an internship, and I’d be thrilled to get another one next summer.

Summer’s a great time to do all the things you’ve been wanting to do, but haven’t found time to do during the year. In my case, one of those things was regular, high-intensity exercise. Coming into the summer, I did what I do every year: I said I would devote my summer to serious exercise and try to develop a more regular exercise routine for myself. Every summer before this one, I’d exercise a couple of times, but I’d always get caught up in everything else going on, and undoubtedly working out would get put on the back burner. Something changed this summer, and I actually managed to start running and working out on a regular basis.

At the beginning of summer, I took my brother’s advice and set monthly exercise goals for myself. They were ridiculously ambitious, but it was motivation for me to strive to meet and surpass them. I also decided that since I wouldn’t have that much time to exercise (I’m working full time over the summer), I’d have to make the most of each workout and do very high-intensity activities. I started running on a regular basis, and eventually I’ve built the habit of running at least four or five times a week. It’s gotten to the point where I enjoy running and I actually look forward to my runs each day.

I used to run a bit during high school, but it was only as supplementary training for soccer, and I never really enjoyed it. Now however, I run for the sake of running, and I want to build up my performance so that I can start racing. The hopes of racing and competing is amazing motivation and really helps me push myself during my runs. I also really want to run a marathon in the near future, so I think of every workout as a step towards achieving that goal.

So what made this summer different from all the other ones? I think one of the biggest things is that I’m older and a lot more determined. I’m a lot better at following through with my goals and actually doing the things I set out to do. It also helped that I wrote down my exercise goals for the summer, and I look at them every once in awhile to re-motivate myself. It’s also a lot easier to make exercising a habit, when you have a daily routine that you can just incorporate your workouts into. For me, I had work every day, so I would go running every day before work (also before it got to hot outside). Compared to the last few summers, when I didn’t have to wake up at the same time every day, it was a lot easier to make running a part of my schedule when my schedule was already well defined. The last thing, and I don’t know how much of a factor this was, but one of the other interns at work is a marathon runner, and he has really inspired me to train. When I look back on how different this summer was from the previous ones, it’s easy to understand why I’ve been able to train so consistently.

Once you make running a habit, it’s actually really easy to get better and keep it up. I’ve been really happy with my improvement, and it just motivates me to run even more. One of the most important things, though, is that if I stop for even one day, it becomes really hard for me to start up again. So last week, I didn’t run at all until Thursday, because I took a day off the week before. On that Thursday, I decided to just go out for a slow run just to get back into things, and now, I’m back into my regular training schedule. Even if I go for a short or slow run, just running every day makes it so much easier to motivate myself.

When school starts in about a week, everything is going change. For one, my life isn’t going to be so nicely scheduled. On top of that, I’m going to have a lot more work outside of class, and finding time to exercise is going to be a lot harder. My hope is that I’ve made running enough of a habit that I’ll keep it up during the school year. Looking ahead, as my schedule becomes less rigid, I’m going to have to somehow incorporate running into my daily routine, so that I don’t lose the habit and have to start all over again.

I’ve got a lot of ideas for articles that I want to write, and not enough time to write them all, so here’s a list of some of those ideas. Hopefully I’ll enough time to get around to all of them in the next couple of weeks.

1. Summer – a brief recap of my incredibly uneventful summer.

2. What I learned at Tellme – my first work-experience and what I took away from that (this will probably be a list). Naturally, I’ll only write this one when I finish my internship on Friday.

3. I’ve got another idea brewing that I’ll start working on soon. I can’t give away any other information because it’s a secret

4. Moving in and running a house – I’ll be moving off-campus this year, so I may end up writing about how my house-mates and I are coping with bills, chores, and everything else that comes with a house.

5. Running club – I intend to join the running club at school, so I’ll probably write something about joining, meeting everyone there, and the runs they go on.

There may also be some more album reviews and book reviews (if I find good albums and read books). The finance thread will probably be pretty stagnant for awhile saying I don’t know enough about the field and don’t have time to learn about it right now.

On top of all of this, I intend to make the design a little more intricate (maybe AJAXy, but definitely more dynamic). I don’t really like this new layout, but I’ll keep it for a bit, mostly because I don’t have the time or patience to make a new one.

Sadly, this is the only book I’ve actually finished this summer (and yes, I haven’t read the new Harry Potter). However, this book is absolutely amazing, and I highly recommend it to any hacker or anyone else remotely interested in programming. Spolsky selected a great set of articles that are very relevant to modern day entrepreneurship, management, and programming. It’s a pretty easy read; most of the articles are fairly short, but it does get technical in parts (I didn’t understand some of the articles), so it might not be very accessible to non-programmers.

The book is a compilation of articles, blog entries, and talks, written and presented by some of the leading software developers in the world. Joel Spolsky is a pretty famous blogger, and he did a great job gathering some really good software articles that cover most of the things a programmer cares about. The articles vary in subject from very technical articles about programming languages, to talks about various companies and managerial tactics, to analysis of online social networking sites. A lot of the article authors are pretty famous bloggers: Paul Ford, Aaron Swartz, and of course Paul Graham. To top it all off, the articles and Spolsky’s commentary are peppered with sarcasm and humor.

The work Spolsky did in the novel was quite good. His ordering of articles makes the book flow very well, even though it’s a compilation of disconnected articles. He has grouped articles in sets, one set being more about software and programming, one set being about teamwork, management, and hiring, and one set being about social networks. To add to that, he’s injected humorous elements like cartoons and sarcastic articles to lighten the technical mood. His introduction to the articles do a good job of presenting a high-level abstract for the article without getting to in-depth and repetitive. He also often includes his own opinions and short anecdotes which provide a different perspective from the writer of the article. All in all, Spolsky’s done a great job as editor of “The Best Software Writing I”.

The articles themselves are for the most part excellent. Again, some of them are quite technical, but they can easily be skimmed over or skipped entirely. Most of them are very accessible, and don’t actually talk about programming, or even software. These articles are mostly about management, hiring, or social networking. These were my favorite articles because I’m currently designing a site with social networking concepts (Wenote) and also because I’m going to be looking for internships and a job pretty soon. They’re probably the most relevant to me. I could relate to most of the articles, which made the book a lot more interesting on the whole. There were a few bad articles though. The last article: a short Ruby tutorial tried too hard to be funny (it really wasn’t funny), and didn’t really provide any insight.

On the whole, the book was an excellent read. Part of this may be because I’m really interested in software development and pretty much every topic addressed in the book, but even still, every article is very well written. If you’re interested in programming languages, software, how companies operate, managerial tactics, or social networking, pick up this book and at least read the articles that you care about.

Rating: 9/10

Pros: Funny, insightful, relevant

Cons: small audience, too technical at times

After being online for about a month, Akrish.net is finally on Google’s search engine. It’s the first hit if you search for ‘akrish.net’, and it’s the second hit if you just type ‘akrish’. Hopefully this will result in a lot more traffic on the site. Thanks to everyone who linked to me (the only one I know of is Prashant) as that’s how Google’s crawlers got here in the first place. Also thanks to all the people who’ve been reading my entries and giving me feedback on them.