Advice to young developers

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:

  1. Think first, code later.
  2. Learn how to use version control and bug tracking software.
  3. Listen to your elders.
  4. Question everything.
  5. Get out of your comfort zone.

[Read the rest of this entry…]

Annoyed people quit

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.

[Read the rest of this entry…]


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.


Must read books for every developer

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.

[Read the rest of this entry…]

Issue tracking for beginners

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…]

Crunch-time development

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?

[Read the rest of this entry…]


To be honest, I have been meaning to write this post for years now, but never got around doing it. It took a recent incident (yes, let’s call it that) to remind me of this topic.

You know, priorities are funny. We are taught about priorities since our birth, yet, when we reach adult age, there are still people who seem totally incapable of understanding and handling priorities. The problem is that priorities are highly subjective and totally dependent on a person owning a task. That is why, you never ever let customers set priorities when reporting issues. For them, every issue is uber-important and thus has high priority. In reality, fixing a typo on an internal web page that only 1 person visits once per month can hardly be as important as let’s say, public application crashing, but that won’t stop people calling you up every 2 minutes and asking why the typo still remains.

But I understand all that. It is the same problem when you call admins that one of your specialized test servers is not working correctly and they don’t focus every inch of their attention to it. Understandable, they have more important work. What I don’t get is developers refusing to assign priorities to tasks assigned to them. There are so many benefits related to priorities. You get a better overview of which tasks need to be solved now and which can wait (and which can be thrown out and buried in the yard). You get better chance of hitting the deadline by not doing the tasks that are simply not important. You get more precise deadline. And you get to see if you have been “taking one for the team” a bit more than others and then complain to your boss.

But no, developers and project managers tend to leave priorities to default and then pretend that everything is equally important. And then you get developers painting a background of a textbox pink instead of churning away on important feature that will bring you profit and reputation. But hey, pink textboxes are important as well.

Quick tip: Compile and deploy web application from command line (or script)

Sooner or later, your .NET web application project will gather helping hands and it is at that point that you will realize that deployment from Visual Studio is just not good enough. Yes, I know Microsoft did a grand job with their deployment scheme in Visual Studio, but let’s be honest. That only works if you are a single developer working on a single environment. As soon as you have to do regular integration, testing and production deployment, Visual Studio fails. More hands on a project only makes things worse. This is not a critique. Visual Studio is development tool, not a continuous integration tool.

So, to positively answer Joel’s second question, you will need some sort of build and deployment automation. Sure, you can use TFS, but that costs money and a supercomputer and let’s be frank, most small shops cannot afford it. So, what you will end up is either some open source CI tool like *cough*CruiseControl.Net*cough* or write your own scripts. Whatever you use, you will find yourself in a peril building and deploying .NET web application. Why? To publish .NET web application building it and copying it to server just won’t work. The easiest way to do it is to create a package and deploy it to your IIS using MSDeploy extension. So, how do you go about that?

To create a package execute following command line expression:

Obviously this is for 64-bit systems using .NET 4.0 and 4.5.x. You can package your app for 32-bit systems using same expression by just removing 64 from Framework64 part of MSBuild.exe path.

Now that you have your deployment project ready, check MyWebApplication.SetParameters.xml file located at D:\path_to_my_project\bin\ folder and change IIS web site and name, if needed. Also, connection strings used are in that file, so you need to pay attention, if everything is set accordingly. Finally, you are ready to deploy:

There are ways to run deploy command file with another user, but that will take some server tweaking on your side. Anyway, after the command completes, you have a running application.

Creating transparent CStatic control in MFC

For a side project, I am working on in my spare time since college, I needed to create a splash screen. Finally. Eleven years after version 1.0 and we are thinking splash screen. Anyway, the splash screen must contain a custom image as a background, a progress bar to display how the initialization is progressing and something that will show every step of execution. Steps completed must be stacked on top of current step. Needless to say, application is written entirely in C++ using MFC framework and said splash screen, naturally, must be part of the application and not a separate project.

[Read the rest of this entry…]

Absolute positioning = evil?

When I started to learn how to develop web pages, CSS was in it’s beginnings. It was in state that CSS3 was two years ago where each browser interpreted it in it’s own way and half of the stuff didn’t work in one of available browsers. This meant that unless you had a huge desire to limit users to certain browsers, you ended up with a web page that looked something like this:


Anyway, as years progressed and we got better and better browsers and newer CSS standard, styling became easy to do. Suddenly you were not supposed to use tables for positioning or frames for layout any more and anyone still doing it was quickly out of business. Instead we started doing things with CSS.

Positioning in CSS is still a bit tricky and you have to learn about stuff like box model and why it didn’t work the same in all browsers. This is when two techniques developed. Either you positioned elements in-flow (from left to right and top to bottom) or you did it with absolute positioning.

Now, absolute positioning is not all that bad, provided it is used wisely. However, and this is my opinion, you should only absolutely position elements relatively on it’s container. Using absolute positioning to position everything breaks the flow of the document and can lead to lots more work once changes need to be applied to the layout.

I think user Bryan M. of StackOverflow sums it up nicely:

I think the problem is that absolute positioning is easy to abuse. A coordinate system is much easier for lay people to understand than the box model. Also, programs like Dreamweaver make it trivially simple to layout a page using absolute positioning (and people don’t realize what they’re doing).

However, for typical page layout, the default static positioning should be adequate and get the job done 90% of the time. It’s very flexible, and by keeping everything in normal flow, elements are aware of the other elements around them, and will act according when things change. This is really good when dealing with dynamic content (which most pages are these days).

Using absolute positioning is far more rigid and makes it difficult to write layouts that respond well to changing content. They’re simply too explicit. However, it is perfect if you’re in need of freely moving elements around a page (drag/drop), need to overlay elements on top of each other, or other layout techniques that would benefit from working on a coordinate system. Frankly, a chessboard sounds like a fine reason to use it.

So is absolute positioning evil? Yes, but not in every case. Positioning something absolute relatively to it’s container is fine, if there is absolutely no way to position element using regular in-flow positioning (close x icon for modal dialog pops to mind). However, if you are learning CSS, I would definitely advise you to learn the box model first.