Over the past few years, I’ve tried a few types of blogging. I’ve tried the technical type articles, high level musings/rants, and everything in between. But lately, I’ve been feeling an urge to go back to my roots.
So, kicking off with my most recent post (earlier today, in fact) about SQL Server Management Objects, I’ve decided to focus more on the technical aspects of subjects I have an interest in. But this time, I plan on taking it a bit further.
**Austin Powers’ voice** GitHub baby, yeah.
Essentially, for all the technical entries I attempt from now on, I will be posting my source code for all the world to see. I’ve decided to go down this path for a couple of reasons;
- I don’t code much these days. I feel as time goes on, I’m getting rustier and forgetting the interesting – and even the basic – things I’ve learnt about code over the years. By focusing on more technical articles, and making the effort to post the code online, I believe this will help me sharpen my coding skills and keep it all relatively fresh in my mind.
- Slightly to related to item 1, I also want people to suggest improvements to my code. This way I’m learning from people with far more experience than I, and hopefully helping other people out in return with the general content of my work.
Another thing I’ve added to my to-do list, is to search for a new blogging engine and hosting provider. While WordPress has been good to me, I’m starting to get an itch that I realise is a general dissatisfaction with the platform and the limitations it imposes (counterpoint; its free, so I understand its a case of you get what you pay for). I think I will have a look into Azure as a host, and a couple of the open source blogging engines I’ve seen floating around GitHub.
So join me dear reader, on yet another wonderful journey of amusing mistakes and lessons learnt… Now with added shiny code™!
On the whole, I enjoy writing as an honest to goodness hobby. Once I start writing my brain goes into the zone and I’m madly typing a thousand words or so in a very short time, and usually its fairly coherent. Lately I’ve been taking notes on potential future personal projects, but I’ve been seriously struggling to find the motivation to start just the initial investigations required for these projects. And dont even get me started on my technical blogging
So, with that in mind I’ve decided to start accelerating things a little bit but using an alternate approach to ‘CODECODECODE’. Firstly, as a mixture of hobby and personal development I’ve started a gaming blog. I am a HUGE gamer… my passion for gaming quite often overrides my common sense so its definitely a subject I know a lot about, and have a lot to say. The point of this is to try and get into the habit of writing. I’m a firm believer in that writing is a really useful skill as a developer, as we are required to be coherent in a number of different aspects (writing specs, talking to clients etc) and a blog is a good way to hone those communication skills a lot of developers seem to lack. So while its not really technical as such, at the very least its giving me practice in making my thoughts about various subjects clear and focused.
The second of my two-prong attack is these personal projects I’m talking about. I’m going to start setting REALLY small goals for these, as I tend to get overwhelmed by the scope of my ideas, killing it before it begins. For instance… by the end of this week I plan to have a new dev VM set up, with Windows Server 2012, VS2012, SQL2012 and BizTalk Server 2013. If I can have that accomplished, I will be a very happy camper. And next week perhaps some initial investigation into the simpler projects I’ve thought of. Next week is a long way away, so I’ll leave that up in the air for now (you’re on the edge of your seat right now, aren’t you? 😉 ).
Feel free to share your experiences in tackling your own personal development below, I’d be happy to hear someone else’s approach to this.
The developers of today live in a Golden Age… That is to say an Age of Google, where developers joke (not so jokingly) about Google being the only reason they still have a job. Think about it; an entire generation of developers who rely so much on ‘The Google (TM)’, that any time we get any sort of error or issue we don’t expect BAM straight onto Google (or StackOverflow). What would happen if tomorrow, both StackOverflow and Google both died instantaneously, never to be revived (ignoring the fact that someone else would most likely knock up a replacement pretty quick)?
The shit would hit the fan, hard and that safety net for developers everywhere would be gone.
Over the past year or so I’ve tried not using Google and StackOverflow for my troubleshooting issues (see here), and its been an interesting experience. I’ve delved into areas I otherwise wouldn’t go into (because once we see that magical fix on Google or SO, we don’t look into any further because we need the problem fixed NOWNOWNOW), and while it has been more difficult and frustrating it’s helped me actually understand the problem at hand. And to be honest while it does take me a bit longer to get things done, I like it because I actually learn something, and better yet – and this is the part most people will struggle with – retain something. In the Google Age of ‘Search and Forget’ (ie. Search for a problem, fix it and then forget it) information retention is sorely lacking. We (and I’m guilty of this myself) Google the same things over and over our mind filters out the ‘quick-fix’ of information we sift through on a daily basis.
Originally this post was going to be about what you, as a developer, use as your most valuable resource/s and how much we love them, but once I started typing I kind of went off track a bit. But you know what, I think I’m going to keep it like this, and leave you with a thought experiment…
The next time you have an error or problem you need resolved, ask yourself what would you do if your MVR wasn’t around to help you out? How would you go about troubleshooting or fixing the problem? Instead of jumping onto your MVR site, actually take a step back and try to look at the problem at hand. Research the concepts around whats going wrong (you can use Google for this!), or what you’re attempting to do and compare it to what you’ve done. Who knows, you might just learn something you didn’t expect 🙂
One thing Ive come to notice since I started this blog, is that writing is bloody hard…
See, now I really enjoy writing. I find myself able to express myself quite clearly through the written word and since starting this blog I feel my writing (both technical and non-technical writing) has improved and I (like to) think some people even enjoy reading it. Writing is fun, because alot like other art forms (of which I consider software development one) you start with a blank canvas/page/screen and you create something.
But, again, writing is hard.
Ive had quite a few posts where inspiration hits and Im madly typing out about 1000 words of writing in 45 mins and at the end I feel pretty darn good about it. I come back to the post a week or so later, look at the post and just think ‘um… this is kind of crap’. I find grammatical errors, the odd spelling error and (to me, this is the worst) Ive expressed myself poorly.
It seems that, alot like code actually, the first cut is always pretty crap.
I suppose thats why writers/authors/poets go through several drafts of their work before they consider it submittable. Ive recently being doing a bit of reading on a site called Joel on Software. I find myself inspired by some of his posts… the quality of his writing is a cut above what Ive read so far on the internet and I honestly believe its something we should (bloggers or not) aspire to. This is how I want to be writing.
Im going to be dedicating a bit more time to my blog from now on… The aim is to set a certain amount of time aside per week and actually plan out my posts. Throw ideas around as to what Im going to write, and most importantly do a few drafts before I hit that shiny magical ‘Publish’ button.
If you feel so inclined, share your writing experiences below and any sites you consider the author to be a darn fine writer.
Ive been thinking alot lately about work, and how much it can take over your life unexpectedly. One moment youre enjoying your days (weekends, even!) and the next you are neck deep in support tickets, code changes and project work. While this certainly doesnt make for a boring work life, once things really get intense you start to forget how much you actually enjoy programming! It becomes a chore, a case of ‘sigh, another day *grumble grumble*’. Ive realised this over the past few months that I have been completely consumed with work, and in doing so stopped enjoying the very reason I got into programming in the first place…
That urge to discover, create and mold what you see.
Damn, its been that long since Ive actually programmed for the pure joy of it its given me a yearning (oh yes, I just used the word yearning) to work on some personal projects of my own… Nothing too big, more ‘for the fun of it’ type stuff than any serious applications. And as a result of this I have chosen to join the open source community, in this particular case GitHub. GitHub is a site which encourages the collaboration, creativity and passion for programming (all shapes and forms) and enables anyone to contribute to any project that catches their eye. These are people who, apart from their daily grind, choose to spend their spare time creating something wonderful, with people who share their passion for development. This sounds like a mighty fine place to be.
The smallest ideas often cause the greatest change, and I find the best example of this with the guys over at Code52, and they have a very simple goal; ‘A new coding project every week’. While they havent quite met this goal, some of the applications theyve created are amazing, with the base code created within an entire week. I find this sort of thing staggering in the most wonderful way… Most people I know (even people in IT) consider their job as ‘just a job’. While theres nothing wrong with this, for me personally I have a passion for this sort of thing. Not just the technical side of it either but the reasons why we develop (to me, this is almost more important than what we do but thats a post for another day). They are trying to introduce the open source mindset in small, easy to manage projects. This gives exposure to those too intimidated (ie. me) to contribute to the random projects you can see on GitHub and the like. This is passion.
So Ive decided to take the plunge. Once things quieten down a bit of work and I have some spare time again Ill look into contributing into some of the Code52 projects, for no other reason than to learn how other developers work, and see some slightly more varied codebases as Ive been with my current employer for almost 5 years now, with the same codebase (plus a few bits and pieces) so it will be very interesting to see other perspectives and other thought processes in action.
Night all 🙂
I had an awesome day today.
Not because of any new technology, or interesting piece of side work (though those are fun), but because today I was asked to fill in for the daily support tasks at work (our main contract is a support contract, with all of the investigations, bug fixes, data fixes and enhancements that come with it). You see, over the past 4 months for the most part Ive been on project work so it was a bloody nice breath of fresh air to get into the support queue (which we call Pending Technical 😉 ), and really hammer it down and get things done.
So as I was churning through the queue, relatively quickly, it got me thinking about support work in general and the various ways you can be of service to your client, while at the same time learning new things and staying interested in the work you do. Which brings me to the inspiration of this post… Effective Support.
I’m starting to realize, 6 years in, that support work is a really good grounding for developers, in various ways…
The first of these ways is troubleshooting; there’s no point being a fancy-pants developer, writing reams of code if you cant troubleshoot issues when (and they will!) start to appear. I find the grounding Ive had in troubleshooting over the past 5 years (how long Ive been working for my current employer, and my current client) has really enabled me to think on my feet, diagnose issues quickly (and usually correctly), and resolve them. Or if not resolve, at least put forward to be fixed. The Client wants results, even when the results may not be what they want to hear, and they would still much rather know whats going on so they (or you, as the case may be) can get it fixed as soon as possible. Not only that, they’ll appreciate the speedy response. Take too long, too frequently, and the Client will start to develop an apathy towards your relevant ‘Pending Tech’ queue, with little or no expectations. This is a Bad Thing… When the Client stops caring, they start looking somewhere else.
The second of these is communication; in the support world communication is everything. Whether it be written or verbal, communication will make or break a support ticket. Being clear in what you require from the Client will go a long way towards resolving your current task. If you get a ticket that makes no sense, like vague issue descriptions for instance, pick up the phone and call them directly. Don’t be afraid to talk to the Client… Ive found a single conversation will often resolve a multitude of issues, as you get instant feedback as to whats going on. Even more important than picking up the phone… See your Client. Most companies that outsource will have some sort of hot-desk arrangement, so talk with your manager and try and book at least half a day at the Client site per week. While there will be times where its simply not possible, the Client will always appreciate seeing the people on the other end of the line. If you stay stuck in a room with 4 walls, with no contact to the outside world, the support tasks you are responsible for will suffer, and even worse yourrelationship with the Client will suffer. Great communication with your Client leads to a great relationship with your Client… Which means you get to keep your job 🙂
Thirdly is maintainable code; again, using the fancy-pants developer example, there’s no point being so wonderful and awesome if the next guy that comes in doesn’t at least have a basic understanding of whats going on. While there are always going to be some areas that will be more complex than others, your code should be clear, concise and (I cant emphasize this enough), clearly commented. Now, I’m not saying that you should comment EVERY SINGLE LINE OF CODE IN EXISTENCE!!! (Imagine that shouted in a deep, echoed voice), but I am saying for areas that aren’t immediately clear, or require a deeper level of understanding, comments should be included to help the next developer in his/her mission to understand what you have done. I find, having been on the short end of the stick a few times, writing maintainable code from the start will go a long way to remaining effective and agile for your Client, otherwise your estimates will be bigger due to having to deal with the mess of code left from before. Lower estimates mean less money, which makes the Client happy, which means you get to keep your job 🙂
Lastly (for tonight at least) we come to business knowledge. Or ‘Domain Knowledge’ if you prefer. While we, as developers, will never have quite the understanding the Client does of their business (and Ive noticed we always tend to have a technically skewed view of things), it should be our job (especially as support developers) to increase our knowledge of the domain we are working in. Get use cases, functional requirements, policy documents, ANYTHING really you can get your hands on, and try to increase your level of contextual understanding of the business (how/where your application is actually used, and how the users use it). I think that business knowledge, in combination with communication can really enable your team to excel in the support environment, and are the most important points of what I’m trying to get across with this post. The Client always respects those who actually care about the business they represent, and who make the effort to truly understand what it is they are supporting. And with that respect, you get to keep your job 🙂
I hope this post has enlightened you, the reader, in what I believe to be three key points in giving Effective Support to your Client. Feel free to disagree/agree/modify my points in the comments, discussion is encouraged 🙂
Hobbies are awesome, and in my particular line of work more often than not our hobby is also our career, or if not this, then something computer related (personally, Im an avid gamer).
Im still not sure if this is a good thing, as while it does give us a passion for our work, and a drive to investigate deeper and further, sometimes things can go out of balance. For instance, you spend 8 hours of your day in front of a computer for work. You then get home and spend several more hours (depending on the level of your passion) investigating/reading/mucking around with other areas (or gaming). So you can get to a point where you spend about 15 hours of your day in front of a computer. This brings to the fore all sorts of medical issues over time; RSI, back pain, eye strain and headaches.
The reason for this post is to ask you this question: When was the last time you actually spent time doing something not computer related? Recently, Ive been making an effort for a better balance in my life for my computer/non-computer activities, and oddly enough Im enjoying it. I feel happier overall, and to be honest a bit more switched on when I do work. Ive started reading (non-technical) books again, and Im even making an effort with the garden.
The problem with being a tech-inclined person, I think, is our tendency for our hobby to become an obsession (although I suppose the same can be said of any hobby or interest). There is a crazy amount of information out there, and our passion wants us to know it all. Im starting to realise not only is this not realistic, but unhealthy to boot. Theres nothing wrong with being passionate about what you do, but you need to be careful how far your passions can take you, and develop the ability to be able to pull back before you fall down the precipice of obsession.
Its not a fun place.
I thought I would share an experience with you all…
Recently I had a deployment go out into production. At the time, the build went very smoothly; no issues with the deployments of the websites themselves, the db schema update and post update scripts went through without a hitch. Wonderful!
Or so I thought.
Came in the next morning (and isn’t this how it always happens?), and about 9am we started getting suspensions in our BizTalk orchestrations. ‘Access Denied’. Hooray for 401 errors! An awesome little birdie informed me of a very basic mistake and left me to figure it out. So I trawled through our staging folders, checking and double checking the folders and files. Then I saw the answer to this problem.
Oh yes, Id forgotten to copy the relevant production configs (specifically these ones defined what service accounts had access to the web sites) into the staging code. The parent web.config was OK, but the inner ones within the web sites had the dev service accounts listed in the file. Silly me.
So, an emergency change (blurgh) later and we had the proper configs in production, and all was (relatively) well.
Once the dust had settled, I decided to fix things so we never, EVER had this sort of issue again. And so, this brings me to the title of this entry – Automation is your friend. I modified our deployment script to copy the configs to the staging folder, and THEN copy the code to the relevant production servers. Problem solved 🙂
This got me thinking about automation in general, and how amazingly wonderful it is. Repeatability is what we, as developers, should aspire to. Because repeatability equals successful tasks, which means less time troubleshooting random or unexpected issues. Just for fun, I thought Id list some of the automation tools we use:
- CruiseControl.NET (Continuous Integration)
- Powershell (IIS/BizTalk Deployments)
- Batch Files (Bits and pieces that dont quite fit, although the more I use Powershell, the more I realise that batch files are reduntant in my eyes)
- SQLCMD (For SQL Script execution)
We also recently started using SQL Stored Procedures to automate some of our basic scripting tasks, as our main application is very reference-data driven, so when we are creating new entities, the amount of SQL we need to script is dramatically cut down. This is the second most awesome thing Im proud of in terms of what we’ve introduced to make our lives easier.
The most awesome thing is Powershell. Words cannot describe how much I fricking love this tool, and the power it gives you over your PC. While we are currently only using this for IIS and BizTalk deployments, the utter potential of this scripting language, where EVERYTHING is an object (this is where it has a HUGE advantage over normal batch file scripting) and can be accessed as such is mind blowing. I spent a good few days learning the basics before creating my first IIS deployment script, and it worked perfectly and (in my opinion) is alot more readable than batch files (its a weird thing to say I know, but hey).
Its amazing how many developers dont use automation in their environments. The ability to quickly (but sometimes painfully, depending on which CI tool you use) create a preview environment with a copy & paste job is amazing, and adds value to the client like you wouldnt believe. The ability to be dynamic and reactive to a client’s needs is essential in this day and age, and automation is a huge step forward towards those wonderful ideals.
CruiseControl.NET is our CI tool of choice, and to be honest Im not a big fan of it. Its completely XML driven (which can be a blessing or a curse depending on your taste), which makes it a bloody pain in the ass to troubleshoot sometimes. Saying that though, I do have a pretty decent handle on it now. But thats mainly a result of blood, sweat and tears trying to figure these issues out, as the log files arent always helpful. Ive recently introduced to a tool called psake. Psake is a powershell driven (yay!) scripting tool to create build scripts, without the messy XML. The syntax is clean and straightforward, and after my previous weekend of troubleshooting a rogue msbuild task (and trawling through rather large XML error logs), Im seriously considering the switch. This, in combination with a CI server called TeamCity (by the JetBrains mob) is my next personal project of investigation to see if its appropriate for our team.
So next time you have a tedious, repetitive task that needs to get done consider automating it, as which ever automation tools you choose to use its definitely a step forward from managing (or attempting to manage) everything yourself, manually.
Night all 🙂
A developer should always be learning.
I find this statement (one which I thought up only moments ago, staring at a blank screen wondering what to write) quite profound for me, at this particular point in my career. I say this because over the past 12 or so months I feel like I have stopped learning (MCTS nonwithstanding). This is a mildly depressing realisation, one which I am trying to rectify. You see, in my current work environment I feel confident in saying I know the business quite well. People refer to me for advice (technical and otherwise in some cases), and I get a healthy level of respect from the client because of this. From a technical standpoint (in the context of the applications we support) I know our main system like the back of my hand (I still wish I could un-see some of things Ive seen), and the other systems we support at a decent level, and anything I dont know I can usually find out pretty quickly.
Unfortunately, this is something of a double edged sword.
You see, not only do I like learning things from a technical standpoint (like .Net, Sql etc), but I love learning the business. I want to know every single in and out of the system, and the potential impact a change can make (anticipating these sorts of things will save you many headaches, if not stomach ulcers) on every level from the code to the business process, all the way up the user. Since I work for a government department (through my employer), complex policy changes get me going like a toddler pumped full of red cordial, laced with red bull. Professionally of course.
Anyway, since I have been with this department (and employer) for over 4 years I have a very solid grasp on how things work, and as such Im not learning anything anymore. So not only am I not learning from a technical standpoint (as we still predominantly use .Net 2.0), but from a business standpoint there’s nothing really to sink my teeth into (in saying this, we do have a very big project coming up, so that will help somewhat). So as a result of this, what has happened to me is the worst possible thing to happen to a developer.
I have stagnated.
When you stagnate, two very bad things happen. Firstly (and obviously), you stop gaining knowledge. The knowledge you do have, while useful, doesnt provide any real challenges and you therefore settle into a very subtle and sneaky routine otherwise known as a ‘rut’. Secondly, and in my opinion this is far worse, you stagnate mentally. Meaning your capacity to learn, and the speed at which you learn is reduced. As a developer this is devastating, as the quicker you learn the quicker you are useful to the client. When you are given a brand spanking new piece of work, something thats not even closely related to what youve done before (or in a while), you look at it with a blank stare and think ‘crap, how does this go /go again?’. While this is unavoidable sometimes, we as developers should be doing everything we can to keep our minds sharp.
Recently, I started delving into the world of IoC (Inversion of Control), and the principles that entails. To my (most likely flawed) understanding, IoC involves the separation of the dependencies between parts of your applications (usually between UI and Business Components, although I think it could apply across all layers). And boy, have I struggled with even the basics of this. Thankfully though, the longer I study this (and other things Ive stumbled across so far in my IoC journey), the more I understand. But more importantly, Im understanding new concepts and thought processes alot quicker too! So in learning IoC (which I am beginning to appreciate), not only am I increasing my knowledge, but Im helping keep my mind sharp and on the ball. Crisis averted!
A developer should never be bored.
Look, theres another! Im just flowing with these sorts of deep (*cough*) statements tonight. If you are bored, then you are doing something wrong. Not your boss, your client, or whoever else you are trying to blame, you. Much as it might be frustrating sometimes, the onus is on you to be finding new things to chew on. This doesnt have to be technical either, this could just as easily be Policy Documents, Use Cases or whatever. Anything that helps you keep that ability to learn functioning is pure gold. Failing that, browse StackOverflow (which I have also recently started to do in an effort to kill that nasty boredom), pick some topics of interest and start answering questions! Even if you get some questions wrong (which Im pretty sure I have… that reminds me I need to check that), you still learn from the correct answers other people provide. This also gives you a very good opportunity to sharpen your writing skills, something which I think tends to be underdeveloped in most software developers I see.
So long story short, dont ever stop learning, and dont ever get bored. If you are doing/being either of these things, you could be doing something wrong. Be proactive about it, and fix it before it bites you where it hurts!
Well, tonight I did what I said I would. I went to the ALT.NET UserGroup tonight, with one Garry Stewart speaking, and while listening to these people converse about various .NET related items, I had somewhat of a revelation…
I know nothing.
And yet I feel the bold+underline+italic doesnt quite emphasise how strongly I feel about that, in fact Im almost considering hunting down the HTML (if it exists!) to make that statement flash and blink in alternating colours.
Seriously though, what an experience! It was very refreshing to be in a room of people that know (and I mean really know) what they are talking about. Each and every single person in that room could most likely code rings around me without trying, and when it got to the point where these people are having a good laugh at certain, shall we say, habits or practices that I had no idea were so ‘horrible’, it really was a moment of revelation (as a side note, I stand by regions… Its just up to the dev to not use them like a retard) for me. And its a good kind… I think. Sort of a wake up call to realise how far I still have to go before I can even approach the skill of some these people, which is disconcerting to say the least. However if you think about it in the long term its definitely a good thing, as it keeps me on my toes and doesnt let me settle too much into my ‘comfort zone’ of the day-to-day tasks I do on the support contract my company works on.
It actually inspires me want to look into these things and seriously get my hands dirty about what goes on inside Visual Studio. It was fascinating to listen to Garry talk about VIM (and the like) and realise how much we as developers can take for granted with these IDEs, and more to the point what you as a developer actually can do, (if you feel so inclined) to expose whats going on under the hood.
I think its gonna be an interesting few months. 🙂