Posted tagged ‘work’


August 16, 2010

Back when I was learning programming and software development in college, I began a practice of learning a new programming language every year. I started with Java, then moved to Perl, C#, Visual Basic, Python, Ruby, Groovy, Scala, PHP… etc. I still think it’s a good practice for every developer. It’s even a recommended practice by many other developers on how to stay in your game. You don’t want to be stuck in a situation later on in life where you have to quickly learn a new language (including new concepts) after you’ve been using the same one for decades. The COBOL programmers learned that about a decade or two ago.

So learning a new language is good. It’s not just good to have the ability to use that language in your current project, which you may not be able to do, but also if you switch projects to one that uses that language. However, even beyond direct use of the language is how learning new ideas and ways of doing things will change your code in your language of choice, or at least the language you have no choice in because it’s the one your project uses.

The Matrix

I doubt that The Matrix was programmed in single language. I bet even an AI uses an abstraction to reduce the processing power needed to design something like that.

Of course, this actually brings me to my second topic about projects themselves. The idea that you should learn a new language every year isn’t really new to many people. However, I think that the idea should be extended further to encompass switching projects every few years as well. In a large project this could mean just switching from one portion of the project to another, but with smaller projects it might mean switching completely to a different project (or at least dividing your time between the two).

The reason behind this is actually similar to why you should learn a new language. By being forced into thinking in the new language and solving problems with a different set of tools, it can increase the breadth of your experience and help you perform better on that original project or ones you face in the future. Similarly, being forced to work on a new project will make you think in new ways about new problems that will help you in old projects and even future ones. If you stay with a single project for too long, you’ll star to stagnate and be unable to really explore and incorporate new ideas that your project’s problem domain doesn’t cover. Lack of exposure to new ideas will prohibit growth. Your resumé won’t be improving, and you won’t be growing as a developer.

Ideally, if you switch projects you would want to switch to one in a different language than your last project. This will help cover both aspects of learning a new language and a new project. While you can always learn a new language in your spare time and on personal projects, you will generally learn faster if you’re thrown in the water as it were. Similar to learning a language by living in a foreign country, learning a new programming language is much easier if you’re thrust into the depths of it with no choice to procrastinate. You have to learn it to work on your project, which will help you gain new insight into development in general.

I’ll be starting this exciting adventure myself as I transition from my current project in Java to a new project in C++/Perl. While I’ve been meaning to for a while, I’ve never done any serious work in C/C++. Being forced into it by having to work on a code base that is primarily in C++ will help facilitate that learning process through experience. I’m excited for the opportunity and I feel that everyone should strive to make those sorts of changes in their work from time to time to keep fresh and productive.

Interesting Work

July 8, 2010

One of my largest problems at my job is finding interesting work or making my work interesting. Without having the physical exertion associated with an outdoors job, having something that keeps you actively engaged not only increases productivity, but also personal enjoyment and quality of life. Basically, if you don’t find your work interesting, you’re not going to want to do it.

My Cat Mischief

My cat sometimes attacks the chair in her more crazy moments. She is always interesting, but I don't work with her.

Finding interesting work, or ways to make your work interesting, is not a very easy thing to do. But I find that sometimes those things that are boring are excellent opportunities to find ways to automate and therefor make a computer do instead. This serves two main purposes. The first is that you’re no longer doing boring work, a computer is. The second is that you just created some interesting work in creating a way to automate the boring stuff. Typically the stuff that’s boring is something that has no uniqueness to it and you have to repeat over and over again, which is the perfect target for automation anyway.

For example, testing is boring. Going through and finding all of the areas where your program can break and trying to make it happen can be a drag, especially when you have to do it for every release. However, creating automated tests is more interesting. This is especially true if you add extra flair such as making lava lamps turn on when a build breaks, or integrating it with an sms service that sends you texts every 5 minutes that the build is broken, causing you to drive back to work at 11pm to fix something wrong with the continuous integration system itself since the ops people decided to shut down one of your auxiliary systems. Ok, that’s less fun.

Having a passion for what you do and having your work be interesting is critical to your success in life. Hating what you do for a living and finding your work boring will just cause you to be bad at your job and unhappy in general. If you’re unable to discover a way to make your work more interesting for you, maybe you should consider changing career paths.

I don’t have any great suggestions for making any boring work fun. I know from experience that I personally enjoy taking any project and attempting to find the most elegant way to solve it with the best performance possible. Making sure that everything has documentation and that the unit tests cover over 90% of the code gives a wonderful sense of satisfaction. But any sort of goal that yields a high rate of satisfaction should be targeted as something to strive for in your day to day working life.

Relating Development To Go

May 14, 2010

This is a really niche topic of discussion. Those who have both practiced software development and played/studied Go may appreciate the relation. If you’ve never played go and are not a software developer… well I can’t really help you there. However, today I found the similarities astounding.

There are a lot of terms from Go that are used to describe the game or situations in the game. Things like “lightness” and “flexibility” where your stones are spread out to cover a larger area but with gaps in the middle. The idea being that since they are spread out you’re not too attached to any one stone and can adjust your battle plan by sacrificing a single weak stone rather than being forced to protect a large group of more valuable, and yet still weak, stones. If you cluster your stones together too much, especially at the beginning, you’re said to be over concentrated and are not being very efficient with your stones. Your stones can become “heavy” when they’re too large to lose, but very difficult to keep from being captured. You are forced to make moves that benefit your opponent more than yourself just to make sure you don’t lose those heavy stones.

Japanese style floor goban. Large board tables like this are often made of Kaya, a rare japanese tree known for it's properties as Go board. They are often very expensive.

What does this have to do with software development? Quite a bit actually, especially if you follow the Agile Development Methodology. When creating a software design, you will be more rewarded if you keep your design light and flexible, able to adapt to new change as it happens. The ability to sacrifice (refactor) a weak section will help your greater strategy of winning (producing a complete product). When pieces of your development get heavy, they are difficult to refactor, possibly because they’re not designed to be tested. When modifying that section of your code, it tends to break other sections. Since you built a bad foundation early on and refused to sacrifice it (refactor), you end up being stuck trying to save a dying design and spend a lot of time and effort for little gain.

Once you’ve sacrificed enough bad designs and followed your test driven development to the proper design, your code becomes flexible and more maneuverable. In Go terms, sections of it become “Alive“. Building off of those sections, as long as you keep to your design principles, makes fixing bugs and developing new structures a lot easier.

There are several ways to play go. There is speed Go, where you give yourself only a few seconds to play your piece. There is Go played with a normal time limit, usually an hour or so for each player with some overtime after that. And there’s games which are not timed at all. Speed Go often results in a lot of mistakes, however you can finish a game a lot faster. The result won’t be the best however, and you wouldn’t want to use it to represent your skill in the game. Regular Go is what is good enough for most people. You spend a reasonable amount of time thinking about most moves, but in general you rely more upon any experience you have than reading out the board. In an game that isn’t timed you can really sit and concentrate on your move. You might think about dozens of possibilities of what you could play and the replies your opponent can make and future moves you would make to those replies, etc. It can take a long time, but the resulting moves can be brilliant at times, and often will result in the best game.

I find that too many people play Speed Go in their development efforts. They’re told “Fix this bug” or “Make something that does this” and they open up their IDE or programmer’s editor or echo and cat and put some code in files trying to solve the problem as fast as possible. Problems are dealt with as they come up. There isn’t really a design per say, just how the code all comes together. The problem with this is that the code created by Speed Code is often very problem specific and difficult to fix and modify. There’s no flexibility, and often pieces of the code are heavy.

The last form, coding without a time limit, can yield some surprising results. I’m not saying that you should give everyone unlimited time to code even the most simple of things, nothing would get done. Nor should you try to get the “perfect” design before coding anything, as what you’ll get in the end won’t be worth the time spent. Rather I think that, especially at the start of the project, some actual thought should be put into what you’re coding. This thought shouldn’t be just in your head however, it should be in the form of Tests. If you write up tests that utilize the code you haven’t even written yet, you can get a good design before you code. If it seems hard to test, try something else. You should be writing and throwing away tests as you work on the design of the piece of code you’re tackling. This is equivalent of reading ahead moves in a Go game, seeing where the pieces might lead.

Of course there’s only so far reading ahead will get you. Soon enough you’ll have to implement what you’ve designed and look at the next piece. However, don’t assume just because you have tests and an implementation and that they all work that you can’t change them any more. Everything you write should be flexible to be rewritten or refactored and thrown away or modified to handle new business rules or requirements. Having the tests in place will make modifying the code easier as you’ll see where things will break and can modify them accordingly.

I noticed this correlation in my own code just today. I was finishing up an implementation before moving on to the more difficult part of my project when I realized that from the structure I have built up and the loose framework that I’ve designed, the “difficult” part of the project was able to be solved in the framework that currently existed. The same framework that I’ve built up and torn down and built up several times over the past few months.

Do Research. Don’t Be Just A Code Monkey.

March 22, 2010

I don’t think that good developers are good because they’re overly smart and well suited for the work. Being smart is definitely a plus as it helps get to the heart of problems faster, but even the blade of the keenest intellect will be rendered blunt by the muffling sheathe of ignorance.

Waxing poetic aside, you can’t do a good job if you don’t know what you’re doing. No matter how good you think you might be, you can be better by research, study, and experimentation. I feel that this sentiment applies not only to programming, but to all matters of life. The driving force behind this reckless abandon in the pursuit of knowledge and research is passion. You might not have a passion for your job, but hopefully you have a passion for programming (assuming your a programmer… insert other career as it will work well enough in substitute). If you don’t, consider finding a different career, one you have a drive and desire to succeed in. You’ll go farther in an area you have a passion for than one you don’t. It’s better to be an expert at a “lesser” career than a bad or mediocre at a “higher” career. No one wants a rocket surgen that doesn’t really have a passion for rocket surgery.

“But how?” you may ask, thinking that just saying to ‘research’ without any idea of what goal to pursue isn’t very helpful advice at all. Well that might be true, but everyone’s passions, interests, and job requirements will differ so saying ‘learn about parallel processing’ or ‘research distributed computing’ or ‘learn Ruby, it’s awesome’ isn’t very helpful either. But there are a few methods you can use to start your exploration.

The main idea is to explore areas around your current job, but perhaps not directly related. Try learning a different language that you could, theoretically, implement your same work project in if you knew the ins and outs of it. Maybe start a personal project at home that uses that language to discover the differences between it and something else you already use. Sometimes the features of one language can give you ideas how to better use the one you’re stuck with. If you’ve ever used closures in Ruby (or another language that has them), you’ll start thinking about your Java or C code quite a bit differently.

Another excellent thing to do is learn a new framework or way of doing things that is not the norm for your day to day job. Let’s say you’re writing web apps that deal with a lot of relational database transactions and data manipulation. Try learning about non-relational databases such as object databases or NoSQL. There are many open sourced, non-sql dependent databases that you can try out to learn how you can store and retrieve semi-structured data in a non-relational way. Try to figure out the benefits you gain with your current methods, and compare them to the benefits you’d gain if you switched to a different one. You probably won’t switch your work project over, most people don’t have the authority to do such a thing, but it’s still useful because you’ll open your eyes to different ways of doing things which will end up translating to useful knowledge in your daily job.

Learn a new language every year. Do personal projects in that language. If it’s scripting, maybe make some scripts to help your day to day life out a little. Knowing how to utilize more langages will help you appreciate the differences of them and allow you to be better able to pick the best tool for a given job. It also doesn’t hurt when someone at the office starts asking for someone with experience in some new language and you’re the one who knows anything about it. Embrace change, and don’t get stuck in a rut.

Learn something new every day. Be it a use for a framework, a new language feature, or just something about your own code. Continually learning is critical in the high tech field, as you’re knowledge goes out of date way faster than a lot of other professions. Letting yourself get out of date is like letting a knife rust. It won’t be very useful to its user for long, and will be replaced if it gets too far worn.

Test your code before you write it. Test Driven Development really works. You’ll end up writing way more test code than you ever did before, which is a good thing. You might also notice that you structure your code differently if you write your tests first. The main idea is to allow each piece of code to be tested individually from any other piece of code. If you have a class that you want to test a method of, you should be able to fully test that method without implementing any other class. Any reliance on another classes behavior should be implemented through mock objects. Keep your code decoupled and program based on interfaces. It might not be a bad idea to look into a dependency injection framework, or to get familiar with the finer points of the factory design pattern.

Learning and knowledge is the key to success in our world. I would much rather have someone who’s passionate and willing to put in some work to learn how things work and how to do things better than the average day to day code monkey on my team rather than a good code monkey. The second can implement things that I ask for, but the first can invent new implementations and design reusable code that is worth 3x the code monkey.


January 6, 2010

I am very thankful for my current manager. I’ve thought about it for a while recently due to managers often having such an effect on the lives of those who work for them. I have only worked for 2 good managers, and I wanted to explain why I thought they were good and what separates a ‘good’ manager from a ‘bad’ manager.

Managers I feel are a necessary evil that have been thrust upon us by the bureaucracy gods who, like the gods of old, are both terrible and powerful. Also like you would find in the olden times there are beings of both light and dark in the realm of managers. Some managers rule through fear and require sacrifices to be made in their honor. Others are more benevolent, helping their subordinates through the natural disasters that the bureaucracy gods would thrust upon them. Working for a benevolent one is one of the greater benefits to some job positions.

A good manager will help a subordinate. They will listen and remove higher level management obstacles. When talking to your manager, if they ask the question “What can I do to make your job easier?” or “What can I do to help you?”, then you might indeed have a good manager. Good ones will often push your ideas through upper management, and sit in meetings to help you do your job so you don’t have to sit in those meetings, wasting your productive time.

A bad manager is quite the opposite. A bad manager will request of their subordinates to fill out forms detailing how they spend their time so that the manager can more easily report to his/her managers. A bad manager will thrust additional work on those they lead, not to make their subordinates lives easier, but to make the managers life easier. A bad manager will often not listen when a subordinate brings up an idea or has a concern, but will instead thrust their own ideas down the throat of those who work for them. A bad manager should never be given a cookie.

If you manage people, you have a responsibility. You should not be in it for glory and the people you are trying to please should not be your manager(s), but instead those who you manage. I’m not saying you should let them slack off or anything like that, but you should be making their job easier and make their work more effective. It might be difficult for you and you might be placed in a position where people give you shit for it, but you should take that shit and not pass it down onto those who work for you but instead shield them from that bureaucratic BS. In the end your team will be more effective and efficient. They will succeed where other teams will fail. By making them look good, you will look good in return.

I am lucky to have a manager that does that. I was lucky to have one in another job once as well. If you find a manager that fits this criteria, promote them to their bosses as much as you can, because you don’t want to lose that shield you’re getting. If you’re a manager who does what I’ve listed on the good side, keep going, you rock. If you find yourself doing stuff I’ve listed on the bad side. No cookie.