This week I gave a short talk at Columbia University about a few things that surprised me over the past two years that I've been working in the tech industry. I wanted to capture those thoughts and expand on them here. Before I begin- one disclaimer: I don't have a computer science degree. I received degrees in Mathematics and Mechanical Engineering from Bard College and Columbia University, respectively. During that time I took computer courses that used Python, Java, and C. Your challenges will depend on your background and unique environment.
Over the past two years I've worked first for a small web shop and now as a fellow for HuffPost Labs. At the web shop I worked on websites and web apps for major corporations and agencies in Washington, D.C. - and this work is almost entirely under NDA. All of the experiences that I'm including here have occurred during my short time at HuffPost.
First big surprise: application features are more important than the quality of the code. In other words, deadlines are more important than writing maintainable code. This degree of this imbalance varies from project to project. But even projects that have been in active development for years still suffer from messy or poorly executed code. As a corollary, in an effort to produce a lot of features with less code, a project will get laden with many dependencies. In school we were not allowed to import any libraries or dependencies that we didn't write or were not part of the core language. Of course this makes sense as we were practicing and learning by solving known problems. Through this practice I developed an urge to reject code I don't completely understand or did not write myself. So when I have to open a project that is dependent on hundreds and hundreds of external libraries I cringe.
Another thing I learned quickly is that communication is often more important or at least as important as productivity. Yeah, that's right. I spend about half my day writing code and the other half talking about code, writing about code, and reading about code. And this doesn't just include talking and learning with other engineers. I also make a point to communicate with my manager about progress or lack of progress. A part of this comes from realizing that most workplaces are highly political. You can't just sit in the corner coding all day siloed from others. This overflows into the importance of engaging with the greater tech community, getting out there and meeting other engineers in your town and on the interwebs.
Also, estimating times sucks. At school most of the problems we were solving had already been done by hundreds of students before us and the time it should take us to complete those tasks was relatively known. In the workplace I am often solving unique problems. I also sometimes don't even know what problems I'll run into ahead of time. Nonetheless, I'm required to come up with a time estimate. Early on I made it a rule of thumb to take what time I honestly thought and doubled it. Be very careful when listening to people who don't code, they always assume it takes a lot less time than it really does.
Finally, the visual presentation of an idea or project is often more important than its build. This is obviously only true for the short term. But it was surprising to have to pay attention to the presentation of a project at every step of the process. People get scared when things don't look good. You could have built the most amazing machine learning algorithm but many people will only care how well it is presented to them. So find someone who is just as passionate about the presentation of your idea as you are about building out the logic. The contrapositive of this is also very true - some of the smartest people have stuff that is completely stripped of design. Have you seen the linux kernel mailing list?