Sometimes a chapter ends in an abrupt and unexpected way, whisking you into the next one with a bit of nervousness and excitement. This past week or so has been one such event… Continue reading “Chapters”
Tag: career
Syntax vs Semantics, Or Career Advice for Aspiring Programmers
A little while back I was introduced to a site called Career Dean. It is a site primarily geared towards college students (and some upcoming high school graduates) working towards careers in the programming / development field. People can ask questions and others with experience in the industry provide answers, which can then be “upvoted” in your typical fashion. I spent about a week on the site sharing what I know where I could and hopefully providing some inspiration to other budding developers. However, I noticed a slightly disturbing trend amongst a lot the questions. Here is a sample of some of them:
- Is the compensation on a person’s first job of significant importance?
- Bored to tears after a month as a Software Engineer. Is it too soon to leave?
- What is the best paying programming language to learn?
As I looked over and responded to these types of questions, I realized that a lot of college students seem to be making a big mistake with their college career. If you’ll allow me, I’d like to provide some “free advice” [though nobody really wants it as my grandfather would say] on the issue. I believe students are focusing on the syntax of their profession when they should be focusing on the semantics. Or to state it differently, they’re looking at their first job when they should be looking at their career.
Continue reading “Syntax vs Semantics, Or Career Advice for Aspiring Programmers”
Thankful Tree 2012
It’s Thanksgiving this week, and while there are always a plethora of things to be thankful for, here are a few I shared around the dinner table with the family this past week… Continue reading “Thankful Tree 2012”
A Fresh Year
As I was wrapping some code up last night on a project, it dawned on me that today is the one year mark with my job at Fresh Consulting. I can’t believe how time flies these days and all the amazing things that have happened in that amount of time!
A “Fresh” Start
It has been a busy and crazy road for me the last few months. Between Qakbot slaying and app writing, I’ve also been working on reading up on the latest HTML5/CSS specs (hence the book reviews), working on an iPhone app, and working some side projects that have kept me up late at night.
I’m please to share that some of this hard work has paid off in the form of a career move for me. Continue reading “A “Fresh” Start”
Three hours a week, that's all I ask…
Being a programmer is rough, especially when technology moves so fast. I’m sure there are about two new libraries, three new APIs, and a plethora of new widgets that have just come out by the time I finish typing and posting these thing.
If you’re working in a standard LOB (line of business) you’re stuck between two perils. One hand there is ALWAYS work to do and programming requests typically pile up before you finish. Where I work, we’re down a couple of folks and with the economy, departments are looking to IT to do more of their “processing” work for them. This makes things even more frantic.
On the other hand, I owe it to myself, and my employer, to keep up with the current trends. This way I can become a better craftsman [Yes, I said that.] and offer new solutions to problems we face in the future. Keeping up with the current trends, in my opinion, also involves understanding common bugs that are happening with various frameworks and seeing new ways to “skin the cat.”
All of this takes time, and a bit of detail. Walk up to your supervisor and say, “Hey boss, I want to take some time to research Framework X and maybe write a little app with it.” and you’ll probably get some odd looks. Some supervisors understand this and will let things go, and others will want you to take your own vacation time to do such things. Worse, they may expect you to do those things on your own time. But with a family and a life outside of the job, who’s going to do that? I will sheepishly admit that I enjoy doing my own projects outside of work [I’m a freak that way], but that’s a different story and irrelevant here.
After doing my own scheming and pondering, I think I’ve finally come up with a suitable solution to this situation:
Three hours a week, that’s all I ask.
Take three hours out of your work week and devote it to doing the “upkeep” of your trade. How you split it up is up to you. Often times I like to take a half an hour in the morning and a half hour after getting back from lunch to “read my feeds.” I’ve collected a large amount of RSS feeds (and read them nicely thanks to Netvibes) and I skim through them looking for relevant articles. I look for articles both directly related to my programming language du jour (.Net) but also for programming concepts in general. I also keep some dibs on some aggregated sites so I can see what’s going on with other programming languages, new and old.
Sometimes I’ll take an hour once or twice during the week and work on a small project using the new framework or technology I’ve been reading about. This is how my Hacksaw application got off the ground a good 3 or 4 years back. I haven’t had much time to do a lot of upkeep since, but with the new release of MVC 3 and Razor, I’m looking to rewrite the application to leverage the new features. It doesn’t have to, but it also helps if the project you work on has some kind of direct benefit at work.
You’d be surprised at what 3 hours (a mere 7.5% of a 40 hour work week) will do to hone your skills, and make you aware of technology at large. I don’t think your supervisor will get too mad either, provided you give due priority to servers that catch on fire and apps that go wonky. But talk to them about it, I think they’ll appreciate the benefits you provide to their overall goals. Don’t forget to share your discoveries with your fellow programmers as well.
Three hours a week, that’s all I ask…
Being a programmer is rough, especially when technology moves so fast. I’m sure there are about two new libraries, three new APIs, and a plethora of new widgets that have just come out by the time I finish typing and posting these thing.
If you’re working in a standard LOB (line of business) you’re stuck between two perils. One hand there is ALWAYS work to do and programming requests typically pile up before you finish. Where I work, we’re down a couple of folks and with the economy, departments are looking to IT to do more of their “processing” work for them. This makes things even more frantic.
On the other hand, I owe it to myself, and my employer, to keep up with the current trends. This way I can become a better craftsman [Yes, I said that.] and offer new solutions to problems we face in the future. Keeping up with the current trends, in my opinion, also involves understanding common bugs that are happening with various frameworks and seeing new ways to “skin the cat.”
All of this takes time, and a bit of detail. Walk up to your supervisor and say, “Hey boss, I want to take some time to research Framework X and maybe write a little app with it.” and you’ll probably get some odd looks. Some supervisors understand this and will let things go, and others will want you to take your own vacation time to do such things. Worse, they may expect you to do those things on your own time. But with a family and a life outside of the job, who’s going to do that? I will sheepishly admit that I enjoy doing my own projects outside of work [I’m a freak that way], but that’s a different story and irrelevant here.
After doing my own scheming and pondering, I think I’ve finally come up with a suitable solution to this situation:
Three hours a week, that’s all I ask.
Take three hours out of your work week and devote it to doing the “upkeep” of your trade. How you split it up is up to you. Often times I like to take a half an hour in the morning and a half hour after getting back from lunch to “read my feeds.” I’ve collected a large amount of RSS feeds (and read them nicely thanks to Netvibes) and I skim through them looking for relevant articles. I look for articles both directly related to my programming language du jour (.Net) but also for programming concepts in general. I also keep some dibs on some aggregated sites so I can see what’s going on with other programming languages, new and old.
Sometimes I’ll take an hour once or twice during the week and work on a small project using the new framework or technology I’ve been reading about. This is how my Hacksaw application got off the ground a good 3 or 4 years back. I haven’t had much time to do a lot of upkeep since, but with the new release of MVC 3 and Razor, I’m looking to rewrite the application to leverage the new features. It doesn’t have to, but it also helps if the project you work on has some kind of direct benefit at work.
You’d be surprised at what 3 hours (a mere 7.5% of a 40 hour work week) will do to hone your skills, and make you aware of technology at large. I don’t think your supervisor will get too mad either, provided you give due priority to servers that catch on fire and apps that go wonky. But talk to them about it, I think they’ll appreciate the benefits you provide to their overall goals. Don’t forget to share your discoveries with your fellow programmers as well.
Your Career: The Microcosm of Your Life Part 2
Last week, I commented on how I’ve been finding a lot of aspects to my career that function as a microcosm to my life as a whole. In particular, I noted how life needs to be “1.0” release, in that we need to get out there and live. If we take too much time waiting to get everything perfect, we’ll never get our life going. Similarly, by getting our life at 1.0 status, we can then slowly work “upgrading or modifying” our life to 1.1 status, 1.2 status, and so on.
Related to this concept is the “how” of going from the various “versions” of your life:
Life needs to be lived in an agile manner.
The idea of “agile programming” has been in the works for a while now. It has seen various names and has undergone various approaches, but from all I’ve seen, tried, and read, the core concepts of agile programming (as listed by the manifesto) are to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
After reading over these tenants, and applying them in some of my recent projects, the focus of programming/engineering/crafting/insert clever acronym here has a shift to put more emphasis on the process. The reason for this is that too often in the older models of creating software, there was a HUGE amount of time devoted to setting out what the finished project looked like. There were rules, workflow models, data diagrams, and LOTS of meetings to establish precisely what would happen with the project. The timeline would then be set, a good 6 months, maybe a year to implement the large system.
The problem with this arises with the fact that the environment the project is designed for is a rapidly changing environment. So three months into the project, workflow requirements must change due to the way business is done. You’re then stuck with a dilemma: alter the project in progress (which starts to create something called “scope creep”) or stay fixed to the initial requirements/design documents (treated as a strict contract) and implement those changes when the process is done. This is just getting the 1.0 version released. Incremental changes from 1.0 to 1.1 suffer a similar fate, though not often as drawn out.
What agile seeks to do is eliminate such a rigid process by acknowledging that changes come fast and furious. To work with this, and still have a successful product, you need to have a workflow that accommodates to change and can deliver updates rapidly. By comparison, your agile 1.0 project will most likely not be as “feature rich” as “traditional” 1.0 application, but the application will be able to adapt easier to business rules changes and getting new features or fixing bugs will move a lot faster in the agile model than the traditional model because the process or infrastructure in which the application was built was designed to handle this.
[That’s all great and fantastic Mr. CodeFreak, but how does this apply to life?]
Thanks for stopping me from waxing eloquent on the 1s and 0s! As we progress through our life, there’s no doubt that changes come at us fast and furiously. One day the water heater dies and the budget for your nice summer sod lawn is gone. You get that phone call saying a dear relative has passed away. You read a new book that contains some wonderful grains of wisdom that you want to apply to your everyday living. You hear a sermon that convicts you of some serious changes that you need in your life. This list can go on and on.
How are we to respond to these kinds of situations? If we are living life in an agile manner, we easily integrate these changes into our life and learn from them. This is because we were expecting them to happen, to some small degree. The exact details are always unknown to us until they occur, but the underlying concept is there. You may worry that adopting a change to your life will make things worse. There’s a chance to that. There’s a chance to most of these things. But the nice thing is that if we’re living our life in an agile manner, we’ll realize that “change item X” didn’t work out as well and we’ll roll it back in the next release.
In facing the pressures and forces in our life, its easy to think, “I know what I need to know, I can handle this. I will stand as firm as a rock and will myself through it.” I’m pretty sure this will get you through a lot of things. There will be something out there that WILL crush you to the ground. If you’re still treating yourself like a rock, you’ll be decimated. Hopefully you’ll get back on your feet, but it’ll be a long and painful process. But consider this, if you stand as a rubber ball, you tend to think, “I know a lot of stuff, but I don’t know it all. Pressure will come, and it will probably squish me flat. But after that, I’ll spring back into shape, having learned something new, and continue forward.”
One thing I want to briefly mention is that while looking at this “agile” manner of living, I am by no means throwing everything out the window with each iteration, or even with the “1.0” release. There is still a clear and concise goal or core to the project (and you), its the process of building and fixing that becomes a little more flexible, in response to the joys and trials of life. My own experience has shown me that there is a core set of values and traits that defines you, and that needs to stay fixed. However, there are a lot of stuff not as important that are open to “revisional change” and probably should be done.
So that’s how I see it, life as an agile process. Flexible to the changes that come, but still driven to make things bigger and better.
I ask again. What about you? What parallels or “microcosms” do you see in your career that apply to your life as a whole? I want to know.
Your Career: The Microcosm of Your Life – Part 1
While I’ve been categorically a geek for all of my life, I’ve only really been a software engineer for about 10 years now, starting with an online profile creator I created for a person using Perl and flat files. [ahh the memories]
From time to time I like to sit and reflect from time to time about technologies old and new, patterns and practices I used in my programs, and projects that have succeeded and failed. In doing this I’ve noticed that a lot of things that I’ve done in “programmer land” also seem to apply to life. For example:
Life is a “1.0” Application
In the realm of programming, your 1.0 application is a significant first step, full of potential and features, but often full of bugs and desired functionality. That’s why you’ll find a lot of professionals snark that they’ll wait for the service pack or the 1.1 release of the application before using it.
The thing to realize though, is that if you waited until you had all the bugs out of the application, had all the perfect features in the application, you’d NEVER get it released. Nobody would get to see the awesome app you’ve released, and you would have any feedback on how to make it better and to fix what went wrong. In addition, no amount of code tests, usability tests, and coding standard can prepare an application for the permutations and nuances of “real world use.” This metaphor gets a little skewed nowadays with the massive amount of applications that are great, but keep the “beta” or “release candidate” status (see Gmail or Windows 7), but these are really exceptions and not the norm. If your application is to be taken seriously, you put it out there at 1.0 status and move forward.
This applies to life as well. There’s no amount of preparation, book reading, and “testing” that would fully prepare me for marriage, kids, and life in general. You do your best to prepare, focus on your fundamentals or semantics (see an old post of mine) and then you get out there and live! Sure you have bugs/flaws in your life, and additional features/characteristics about you are yet to be discovered and implemented, but you won’t discover those with out some real world experience to expose them.
As you live, and the “bug fixes” and “feature enhancements” come in, you eventually get to 1.1, status and slowly move forward. Sometimes a new “version release” of you removes some features you found non-essential or undesired, but that’s the beauty of it. You’re still the 1.0 “core” you, but with a lot of improvements along the way. I’m not sure if we ever reach a 2.0 status this side of the grave. Typically 2.0 releases represent a complete rewrite of the system, or a wide variety of features that weren’t available in the original system. But that’s probably a topic for another time.
There’s a second idea I have that ties nicely in with this one, but I’m saving it for another entry, since there is plenty to chew on here for now.
What about you? What parallels or “microcosms” do you see in your career that apply to your life as a whole? I want to know.
Sup-a-Dillie-O 