In the olden days, when I was just starting my foray into the programming world (you know, late 80s, early 90s) we had this programming courses at our school. In this courses basic programming idea and knowledge was passed to us from old guys (you know in their 40s) with glasses and white lab coats. We also did a lot of programming, but there was a little twist. Each and every programming task had to be done on paper first.
Spell checker? Really? Really. When I look at the code, pages, error messages etc. full of spelling mistakes, my first assumption is that people behind this piece of software just don’t care about their customers and/or code. You can’t tell me you are passionate about your product, when you don’t care enough to make it readable to others. Would you hand out an essay filled with spelling mistakes in high school? I thought so. So why on earth would you tolerate poor spelling and syntax in your code?
I hope that in this day and age we all agree that project documentation is a must and not just an afterthought. No? We should be. But in case you work at one of those places where documentation is frowned upon (“Why waste time writing documentation, when you can code. Right?”), just take my word for it. Investing in project documentation will help you great deal now and in the future. You don’t believe me? Check this out. Better?
You kn0w, I am amazed by abundance of videos and tutorials out there that show you, how “easy” it is to create a mobile app. Sure, creating a “Hello world!” example with a few fields and a progress bar is not difficult, but that is hardly a representative app. In real world, you would want user to authenticate, you would want to store some user data (you know, in case he or she decides it is time to wipe the phone and then regret the decision), you would want to offer some payable services to those users and differentiate between free and pro users etc. etc. Yet, you don’t see tutorials for that. And you know why? Because those things are hard to do right.
In last few months I have been assigned as a mentor to young developer who wanted to work as a student for our company. This is my first foray in being a mentor to someone, let alone a prosperous young talent. The first thing when I was told about this, panic kicked in. But then I started thinking about the time when I was a young developer starting out. What would I want to know? What would I want to learn?
Teaching someone a specific technology is pointless. So what could I teach my apprentice that he can, hopefully, take with him for entire lifetime?
I narrowed the list down to four points. So, to you young-lings, I’ve got this advice to offer:
- Think first, code later.
- Learn how to use version control and bug tracking software.
- Listen to your elders.
- Question everything.
- Get out of your comfort zone.
I’ve been meaning to write this post ever since I read Rands post entitled Bored people quit (and I apologise to the original author for blatantly stealing the title). As far as I agree that boredom is important factor when people decide to quit, years of observation and experience brought me to conclusion that there is one more important reason to quit. Annoyance. Pure and simple annoyance.
I have been quiet for a while now (and I appologise) for two reasons. One was, that I spend 4 days abroad and another that I increased my studies for final MCPD web development exam (Microsoft 70-519). Yes, I know the certification will soon be useless as MCSD is going to take over. But (and you knew this was coming), I have been slowly certifying myself in .NET web development starting way before MCSD was introduced. Since I don’t like leaving things undone, I decided it would be best to complete current certification path and then upgrade.
Anyway, to cut long story short. From this day onward, I have reached MCPD Web Developer 4 certification and you can expect more posts from me in near future.
A few years back, I got suck into a conversation of my colleagues on book reading and it surprised me. And not in a good way. In a conversation of six, four of them didn’t read books (apparently due to lack of time) and one read only popular Sci-fi and fantasy books. The remaining one was me. I am far from being well read, but I still try to read a few books a year on tech and non-tech topics.
If not for books, techies definitely follow blogs. Don’t they? Not really. One person didn’t read blogs. Two followed blogs, but not tech ones. The remaining three had a daily routine to browse most popular blogs and find others, if work took them that way. Looking at results one can conclude that three developers out of six participating in the conversation (a stunning 50%) didn’t have a clue of what is going on in their field of expertise.
I first met Trac several years ago at my previous gig for a cloud project we were developing at that point. Prior to that, we used some in-house support tool developed in Lotus Notes. Prior to that, I used Notepad. And let me tell you, everything you use for issue tracking is fine, as long as you write it down. In these days, Trac seems a bit archaic. After all, there is Jira, there is FogBugz, there is Redmine, there is TFS, to name a few. But the issue here is not in what you use, the problem is how to use it. Issue tracking and project management systems are only as good as users using them. This simply means that the best tool in the world won’t help you, if your users do not know how to use it. [Read the rest of this entry…]
Remember the last time your boss roamed into your office/cubicle and asked you to add this one tiny feature to your project in a week? You were tempted to say it is not possible to do it in the time frame, but then you took into account that it looks and sounds as a small feature and it will probably take you only half the time to do it anyway. Also, it is difficult to say “No” to your boss, right? So you said: “Sure boss, I can handle it.”
In the end, what could possibly go wrong?