Am I a Rockstar Software Engineer?
I just saw a blog on Read Write Web titled "Top 10 Traits of a Rockstar Software Engineer"
I love to code, I love to play with computers. I've always said I get paid to have a hobby.
I do refactor my code as I go. Common code sequences into methods. Data structure into proper objects. Functionally breakdown code into separate files. Very reusable code into libraries.
There is so much available code, that I rarely start from scratch anymore. "Leveraging Existing Code" is one of the biggest time savers out there. I just finished a C# app to manipulate excel spreadsheets. If it was not for other peoples code, I'd still be scratching my head 2 weeks later. Mostly because the documentation from microsoft is horrible. But I was able to find examples and snippets that let me write a nice time saver app in 3 days.
I alway focus on usability. I always write out use cases. For UI code I always story board and get feed back from as many people as time allows. If no one can use what your writing, that is not "Getting Things Done". Don't forgete, usability has to do with the messages and the help text as well. Not just the user interface. We've all seen app that look good, but if something happens, it takes the original engineer to know what the error message means.
I have a saying that might piss of those that have come after me. I assume the next guy isn't as smart as me. This forces me to follow the KISS principle. So I do not try to write ridiculously obfuscated code unless required. It pisses me off when people do it to f*ck with the next guy. Because I thing that is the only reason to ever do it without a great explanation. When that is required, the comments explaining the code is always longer than the code.
Another part of maintainability is documentation. I always try to make sure the "main" code files have comments that explain the overall workings of the project. This is so that the next guy can have a clues as to how things flow. I am not really big on full blown comments. Mostly because I know I can be as bad as the next guy when it come to maintaining them. The exception to this is for common libraries. No one should have to use a library that isn't well documented.
Now, here is my favorite. My tool belt has many tools in it. Perl, C#, C++, sql, expect, bash, javascript, PHP, jsaon, xml, xml schemas, xslt, java, cobol, pl/1, fortran, pascal, autoit, silk. I love to learn new languages and play with new tools. The idea is to understand the philosophy of the tool. How it is meant to be used and how to stretch it's use. How to use the right tool for the job. I am only claiming to have full working knowledge of what I am currently using. You want some xslt, gove me a few days to review the book so I have come back up to speed. Ok, for C++, skimming the 2000 pages required to come back up to sped can take a month.
I do have a few flaws.
I'd have to say my flaws are number "4. uses design patterns". I use design patterns, but I am not religious about it. When designing a larger system I do look at The book. I also believe in another form of pattern. If a very well known book uses a particular coding style, or has a specific approach to a problem I am solving, I will copy it. To me this goes to number 8.
Another issue is number 5, "Writes Tests". I'm big on using debuggers and informal test methods. Normally when I write project plans for larger projects I usually have to fight for time to test and document. So formal unit tests are out. It sucks, but in the last few years I have not been allowed the extra time.
This last one has more to do with when I went to school. In the early 80's a CS bachelors degree took 2 routes. Programmer or mathematician. Taking the programmer route I wrote lots of language parsers. But never took the algorithm analysis class. For Data structures I used Knuth volume 1 chapter 2. So I learned about linked lists of various forms. The math requirements was only 2 semesters of calculus. That was more than enough math for me.
But I always get it done. I said that in my interview at Webroot Software. I had a great back and forth about the meaning of "Get's things done". Done is always a compromise for your day job or your venture. Get's things done becomes "what is good enough to ship". Only with hobby code does Get it done ever mean "I can't think of anything else to do to it for now".
Like a great painter that is never finished with a painting, a software engineer always has a todo list in their code to define done, an odd bug that only you will ever know is there (hopefully).
Am I a rockstar? Not the lead singer. More like the drummer. I keep the rhythm for the group, I get a cool solo once or twice during the show, but the other guy gets the groupies. But I know things would sound like shit without me.
- Loves To Code
- Gets Things Done
- Continuously Refactors Code
- Uses Design Patterns
- Writes Tests
- Leverages Existing Code
- Focuses on Usability
- Writes Maintainable Code
- Can Code in Any Language
- Knows Basic Computer Science
I love to code, I love to play with computers. I've always said I get paid to have a hobby.
I do refactor my code as I go. Common code sequences into methods. Data structure into proper objects. Functionally breakdown code into separate files. Very reusable code into libraries.
There is so much available code, that I rarely start from scratch anymore. "Leveraging Existing Code" is one of the biggest time savers out there. I just finished a C# app to manipulate excel spreadsheets. If it was not for other peoples code, I'd still be scratching my head 2 weeks later. Mostly because the documentation from microsoft is horrible. But I was able to find examples and snippets that let me write a nice time saver app in 3 days.
I alway focus on usability. I always write out use cases. For UI code I always story board and get feed back from as many people as time allows. If no one can use what your writing, that is not "Getting Things Done". Don't forgete, usability has to do with the messages and the help text as well. Not just the user interface. We've all seen app that look good, but if something happens, it takes the original engineer to know what the error message means.
I have a saying that might piss of those that have come after me. I assume the next guy isn't as smart as me. This forces me to follow the KISS principle. So I do not try to write ridiculously obfuscated code unless required. It pisses me off when people do it to f*ck with the next guy. Because I thing that is the only reason to ever do it without a great explanation. When that is required, the comments explaining the code is always longer than the code.
Another part of maintainability is documentation. I always try to make sure the "main" code files have comments that explain the overall workings of the project. This is so that the next guy can have a clues as to how things flow. I am not really big on full blown comments. Mostly because I know I can be as bad as the next guy when it come to maintaining them. The exception to this is for common libraries. No one should have to use a library that isn't well documented.
Now, here is my favorite. My tool belt has many tools in it. Perl, C#, C++, sql, expect, bash, javascript, PHP, jsaon, xml, xml schemas, xslt, java, cobol, pl/1, fortran, pascal, autoit, silk. I love to learn new languages and play with new tools. The idea is to understand the philosophy of the tool. How it is meant to be used and how to stretch it's use. How to use the right tool for the job. I am only claiming to have full working knowledge of what I am currently using. You want some xslt, gove me a few days to review the book so I have come back up to speed. Ok, for C++, skimming the 2000 pages required to come back up to sped can take a month.
I do have a few flaws.
I'd have to say my flaws are number "4. uses design patterns". I use design patterns, but I am not religious about it. When designing a larger system I do look at The book. I also believe in another form of pattern. If a very well known book uses a particular coding style, or has a specific approach to a problem I am solving, I will copy it. To me this goes to number 8.
Another issue is number 5, "Writes Tests". I'm big on using debuggers and informal test methods. Normally when I write project plans for larger projects I usually have to fight for time to test and document. So formal unit tests are out. It sucks, but in the last few years I have not been allowed the extra time.
This last one has more to do with when I went to school. In the early 80's a CS bachelors degree took 2 routes. Programmer or mathematician. Taking the programmer route I wrote lots of language parsers. But never took the algorithm analysis class. For Data structures I used Knuth volume 1 chapter 2. So I learned about linked lists of various forms. The math requirements was only 2 semesters of calculus. That was more than enough math for me.
But I always get it done. I said that in my interview at Webroot Software. I had a great back and forth about the meaning of "Get's things done". Done is always a compromise for your day job or your venture. Get's things done becomes "what is good enough to ship". Only with hobby code does Get it done ever mean "I can't think of anything else to do to it for now".
Like a great painter that is never finished with a painting, a software engineer always has a todo list in their code to define done, an odd bug that only you will ever know is there (hopefully).
Am I a rockstar? Not the lead singer. More like the drummer. I keep the rhythm for the group, I get a cool solo once or twice during the show, but the other guy gets the groupies. But I know things would sound like shit without me.
posted by Mike at
7:37 AM
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home