I’m reading Out Of Their Minds – The Lives and Discoveries of 15 Great Computer Scientists by Dennis Shasha and Cathy Lazere. I’m almost half way through but I just read an awesome quote that I wanted to share:
In the culture of computer science, an idea that works in one situation is called a hack, an idea that works twice is called a trick, and an idea that works often and pervasively is called a technique.
- Out Of Their Minds, 1998
For those of us who get little red envelopes today, happy new year!
After graduating college as a computer science major and preparing to enter the work force, I found that there is a big gap between what you learn in college and the practice of being a software engineer.
In college, you learn the the basics of data structures, OOP, and algorithms. But being a software engineer is so much more than that. At my first job out of college, I was lucky enough to be a part of a great team of engineers. They understood the value of best practices, introducing me to design patterns, the power of open source, and how to approach hard problems.
However, it was very one dimensional. While I improved my technical experience, I really didn’t get a chance to be exposed to other perspectives. What I mean is it was very much like college again. My work was my own work. I studied, researched, and provided answers. I didn’t really collaborate with my coworkers. I was given an assignment and an estimated deadline and I would do it kind of like homework.
At my second and current job, I’ve been introduced to and been practicing agile software development, more specifically Scrum, on a daily basis. I’ve seen the HUGE personal benefits that a software engineer, like myself, can take away from developing software this way.
I’ll break it down through what is known as the four values of Agile Software Development.
Individuals and interactions over processes and tools
While being exposed to version control, bug tracking, and continuous integration systems is great for a resume, working with other human beings is much more rewarding and fun. You develop strong relationships and you are able to learn so much from other people’s experiences and perspectives. Pair programming has helped me develop a better understanding of what I don’t know and an even stronger understanding of what I already know. And it’s not only other developers you develop these relationships with. As requirements change, you interact with people from marketing, product, legal, qa, project managers, designers, and the list goes one. This is something you would never get as a programmer at an IT shop that practiced something like the Waterfall method for development, especially early in your career. You will be pigeon-holed into just being code monkey by the time the requirements get to you. Being able to interact with different types of people allows you to grow your network and it exposes you to different aspects of a business.
Working software over comprehensive documentation
As developers, we just like to get things done. We have a tendency to measure productivity with written code. With agile, we can embrace this 100%. I get to concentrate on writing bug fixes, add new features, refactor code, improving the build process rather than documenting some API that no one will ever need since the code is self-documenting. I take great joy in actually doing what I love doing and that’s coding. However, it is a fallacy to interpret this value to mean I don’t have to document anything. But whenever there is no documentation, don’t blame agile. Just rely on the first value and ask someone what that method does.
Customer collaboration over contract negotiation
Developers don’t usually have face to face time with actual paying customers. Usually the “customer” is some other department in the company asking for a new development feature. The main point to be made here is that you want to engage the stakeholders. Not only do you develop relationships, you gather in-depth knowledge of what problems other people are facing on a daily basis. Understanding requirements is often the most difficult part of developing software. As requirements change, with constant engagement from the customer you have a better chance at meeting those requirements. The other piece of this value has to do with deadlines. Contracts are hard deadlines. In the software development, with all its moving pieces, it’s pretty silly to commit to arbitrary dates six months from today. But if you engage stakeholders into your development process, they have clear visibility into the progress of the project. You don’t have to make excuses for why the project is late. They already know what you’re working on and where you are. How does this benefit you? Well, you get to deliver software that actually meets the customer’s needs. Who’s the rock star now?
Responding to change over following a plan
Nothing is ever set in stone. Being able to respond to the evolution of a project is critical to a project’s success. If you are able to learn to design programs that have the flexibility to adapt to your business, that is one awesome accomplishment. It’s a great feeling to be able to say to a product manager that his requested change is already supported by the system, it’s just a configuration change. The language you are using now is most likely not the one you will be using in the future, if you choose to remain a developer. Being able to respond to this change in sought after skills will benefit you well.
Through agile development, I’ve been able to deliver working software time and time again. I’ve been exposed to all different aspects of the business. I’ve learn what I like and don’t like to do. I’ve learn what pieces of business I’m interested in and the pieces I don’t care much for. I’ve developed some really good working relationships. I’ve tackled some hard problems. I’ve learned to respond and adapt to the change and turmoil of a startup.
Most importantly, I still feel I’m growing as a developer. I honestly believe the best thing a developer can do in their career is to always be learning. Everything else will follow.
“Do it to it” was a phrase that my high school computer science teacher would say after describing the next assignment he was giving the class.
The saying has following me throughout the years. Other than being a variation of Nike’s “Just Do it” motto, I’m not really sure why I still remember it other than it encompasses what really matters when being tasked with something.
Given two options of doing something myself or having someone else do it for me, I find myself often saying that I want to do it. I think it’s just that I want the experience and satisfaction (maybe I’m a control-freak). When it comes to work, I have always volunteered to try out new things or build the next big feature. That’s the fun stuff to work on. If there’s a really difficult problem or bug, although I am hating the bug when I’m trying to fix it, in retrospect I usually feel a sense of accomplishment and pride after fixing it.
I think that’s what a lot of programmers that have passion about code have in common. We really enjoy solving problems, using that brain of ours, and building new things with code. Between the late night deploys, emergency bug fixes, and ridiculous business requests, the challenge, the sense of ownership, and the art of building software makes it worthwhile and oh so enjoyable.
So, open up your favorite IDE and do it to it.
Paul Graham just wrote a very insightful piece that I hope companies take note of. The start of the essay speaks to how important it is for programmers to have the ability to store the entire context of a problem in their head so they can navigate to all the pieces they need to work on. This is key for solving big problems and facilitates effective productivity. Graham goes on to provide 8 ways to help programmers to do this.
One of the ways he suggests is to work in small groups. At my work, we do a lot of pair programming and sometimes 3-way programming. I find this to be extremely effective for the way I code. I enjoy being able to constantly ask if this is the right way to approach a problem or am I understanding the problem correctly. With pair programming, I get immediate feedback by my teammate(s) and it helps to spread knowledge of the code base without having to go through code reviews.
The second half of the essay is what really inspired me to write this post. Graham makes the claim that companies deliberately try to do things wrong when it comes to dealing with programmers.
Graham writes:
One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts.
…
It’s not merely true that organizations dislike the idea of depending on individual genius, it’s a tautology. It’s part of the definition of an organization not to.
…
The weakest point in big companies is that they don’t let individual programmers do great work.
Moral of the story: Create a work environment where developers are truly valued. They are the problem solvers. They are the closest to the product. They are the ones bubbling with ideas. Listen to them. Don’t act like a big company no matter what your size is. This is how to beat your competitors.