As a follow up to my last post, I found more debugging links:
If you deal with production servers and you don’t use LogParser, you should. It gives SQL-like abilities to query web server logs an other log types (like Event Logs). Coding Horror has a great article about the tool as well, and a link to a good article about forensic log parsing. Here are my most used web queries:
Find Pages with 500 errors
logparser “SELECT cs-uri-stem as Url, sc-status as code, COUNT(cs-uri-stem) AS Hits FROM C:\ProdLogFiles\ex*.log WHERE (sc-status >= 500) GROUP BY cs-uri-stem, code ORDER BY Hits DESC” -o:CSV >> C:\Data\ErrorPages.csv
Find 404 Requests
logparser “SELECT cs-uri-stem as Url, sc-status as code, COUNT(cs-uri-stem) AS Hits FROM C:\ProdLogFiles\ex*.log WHERE (sc-status = 404) GROUP BY cs-uri-stem, code ORDER BY Hits DESC” -o:CSV >> C:\Data\404Pages.csv
Find the Slowest Pages
logparser “SELECT TOP 100 cs-uri-stem AS Url, MIN(time-taken) as [Min], AVG(time-taken) AS [Avg], max(time-taken) AS [Max], count(time-taken) AS Hits FROM C:\ProdLogFiles\ex*.log GROUP BY Url ORDER BY [Avg] DESC” -o:CSV >> C:\Data\SlowPages.csv
Saw a great post about the Snipping tool in Vista: The Blog at the End of the Universe : Why Vista? (Volume 4 — Snipping Tool). For an old-time Alt+Print Screen guy, this thing is great. But the first time I looked for it, it wasn’t there (I’m using Vista Business). I guess by default it isn’t always installed, but it is available, there is an article describing how to activate the Snipping Tool at PCWorld.
As developers, we struggle daily to be the most productive in our craft. Sometimes interruptions and counter-productive days are unavoidable, but there are number of things we can control to become more productive. These include how we behave, what we do with our work environment, and how we use the tools available to us. This article focuses on the soft skills you can develop to become more productive.
As developers, I am sure we have all experienced flow, or being “in the zone”. You really dig in to your task, time passes quickly, and you just knock out code left and right. This effect is a pretty well documented, and as you probably experienced, it is sometimes hard to get the right momentum going. Often it takes about 15 minutes for a developer to get into the flow, but it only takes a short interruption to lose it. As a developer, you need to do your best to encourage flow. This means minimizing distractions. Be busy or away on your IM, don’t answer it. Turn off your Outlook notifications of incoming emails. Email is not a time-sensitive medium, treat it that way.
One of the best ways to keep your flow effective is to take a break when the flow breaks. You can’t be totally effective and in the flow all the time. Take time to recharge. The flow can’t continue endlessly. When you are not being productive in the flow, take a break.
Keeping focused on the task you are working on also encourages flow. Task switching is an expensive activity; it interrupts the flow. Set aside time to respond to emails and IM’s.
To help keep yourself on task, create task lists for the activities you need to accomplish each day. This is one of the productivity benefits of Agile/Scrum practices, it allows the team to set a daily goal, minimizing task switching. Organize your time to work on those tasks. Being organized helps minimize task switching and last minute tasks that slipped through the cracks while you were busy keeping the flow going.
Few things you can do to increase your productivity have more effect than learning. Knowing the right patterns and concepts up front directly impacts your coding productivity. An article published in Scientific American postulates that experts are made, not born. The article determined that expertise allowed chess masters to easily recognize complex patterns, and find effective solutions in much shorter times than non-masters. This was not due to better analysis skills, but resulted from a larger store of structured knowledge. Experts simply get the job done more efficiently. Additionally, motivation was found to be more important than innate ability when developing expertise. Being better at what you do is simply a matter of putting in the required time to reach the level of expertise you need.
When I am interviewing potential new developers for my firm, one question I often ask is “Do you have a server in your home?” For me this is an indicator of someone who has the motivation to become an expert, they are exploring technology on their own. Obviously not everyone can be a giant in the industry, but the only person holding you back is reading this article. Become an expert, if even in a small space, and increase your productivity.
Obviously, environment affects your ability to get into the flow and stay there. For many of us, noise is a major flow killer. We usually have little control over our direct environment, such as having an office or a cube. But there are actions we can take to make our environment more effective at certain times.
If you have an office door, close it. This is one of the best ways to minimize distraction. If anyone is able to walk up to you and ask a question, they will. Obviously not all interruptions are bad or unnecessary. In order to encourage flow, time needs to be set aside specifically for flow-oriented tasks. Make it clear to others that you are busy, but also make it clear when you will be available again. Take the opportunity to ask to put off a request until you are free.
Set your phone to forward to voice mail, set your cell phone to silent. Set aside time later in the day to answer messages.
If you use an Instant Messenger (IM), make frequent use of the status feature. Others will notice that you do, and will understand that “busy” or “do not disturb” mean just that. Use your email client to schedule work time as appointments. This way you do not look “free” on your calendar or corporate IM.
If you don’t have a door, take advantage of rooms that do have one. Schedule a conference room for yourself for a time when you need to be busy; take your laptop, close the door. This both reduces noise and minimizes distractions, since you are not at your normal location.
Of course headphones are boon to those of us that don’t have a door. Typically, a cube or open environment has conversations going on around you. If you can’t hear them, you are less likely to get pulled into them.
Choosing to work with a strong team will increase your productivity. A strong team environment promotes learning, which in turn improves your productivity. Colleagues or mentors who are more experienced can also enable your own learning and efficiency. Seek them out and learn from them. If you don’t have them at work, find them somewhere else. Look at all the folks blogging, experts abound and they are obvious. Contact them, build a relationship if you can. User groups or developer events, like those put on by Microsoft, or Geek dinners, are another good place to find experts and colleagues.
Next up Part 2: How you can use technology to help you be a more productive developer.
Ran into a performance issue in a .Net remoting situation. A Winforms app is calling an application server asking for data. A relatively large DataSet (>10,000 rows, <6 columns) being passed over the wire was causing a performance problem. The database and application servers processed it quickly. Examining the transfer with WireShark showed that the transfer wasn’t so bad either. There was a flurry of data passed, and then a bunch of waiting on the client-side, with the client CPU usage around 50% the entire duration of the wait. Turns out there is a calculated column in one of the data tables. The column is not calculated on the application server-side, so as not to pass a bunch of data across the wire that would be unnecessary. The calc happens on the client. That was the source of the slowdown and CPU usage. In the end the solution to the problem was not using the calculated column, we found a different solution to fix the business problem. I suppose you could perform the calculation in the SQL statement that was ultimately filling the DataSet. That might take longer to transfer, but won’t slow down the client app.