by Alan Skorkin on May 9, 2010
If you do your development work in Linux, there are certain commands that you owe it to yourself to master fully. There are a number of these with the main ones being grep, find and sort. Just about everyone has at least a passing familiarity with these commands, but with most people the knowledge is superficial, they don't even realise how powerful those commands can be. So, if you really put in the effort to master them, not only will you make your own life much easier, but you will also be able to impress all you friends with your elite Linux skills when you pair with them :). I will cover grep and find (as well as other valuable commands) in subsequent posts – here we will concentrate on sort.
Note: I am using bash, so your mileage might vary if you're using a different shell.
Sorting is a fundamental task when it comes to programming, if you have a decent knowledge of various sorting algorithms, their advantages and disadvantages, you will be a better software developer for it. However, often enough you just don't need to draw on this deeper knowledge. Whether you're answering an interview question about sorting or simply need to quickly sort some data in you day to day work – the Linux sort command is your friend.
by Alan Skorkin on May 6, 2010
A lot of people have asked me recently how/where I get my ideas (e.g. like here) – in reference to the diverse topics that I write about. After what must have been the 10th time someone asked me that question, I thought to myself "…gee, what a good idea, why not write about that…", so perhaps I am not the best person to answer the question after all :), but I do have some thoughts, so I'll give it a whirl regardless.
Ideas are an interesting beast, the more of them you have; the more you tend to come up with. That might seem somewhat counterintuitive or even circular, "…so, ummm, to have more ideas you need to come up with more ideas? Why, that's pure diabolical genius! …” but bear with me for just a minute and I'll explain. Here is the way it goes with most people. You need to come up with an idea – business idea, article idea, book idea, conversational topic – whatever. So, you strain for a few seconds trying to have a flash of brilliance and when the flash inevitably fails to materialize, you shrug, say something self-deprecating like, "… man, I really wish I was better at thinking up ideas. If only I could have a brilliant business idea, I could become a millionaire. Nay, a billionaire! Oh well …". At this point you go back to doing whatever you were doing before and life goes back to normal – which is precisely the worst thing you could have done.
by Alan Skorkin on May 4, 2010
I have strong opinions regarding software consulting and consulting companies, which is probably no surprise as I seem to have a strong opinion about most things :). It's not a bad thing, makes for some lively conversation over drinks, but it is also a bit of a pain as it makes it hard to choose what to write about. I'll regale you with my serious thoughts regarding consulting in another post (don't forget to subscribe to my feed so you don't miss it) – today we'll try to maintain a bit of a lighter tone.
A little while ago I read an interesting book called "The Nomadic Developer", if you are considering going into consulting I recommend you read it (although you would appreciate it more if you've already worked in software consulting). The book has some decent advice and information for budding/existing software consultants, but the thing that really caught my eye was the humorous classification of consulting firms found at the beginning of the book. It was titled "The Seven Deadly Firms" and I thought I would share it with you for a bit of fun as well as adding one more classification of my own to bring the total up to eight. I will quote and paraphrase as necessary – here we go.
by Alan Skorkin on May 4, 2010
I have recently written about the value of fundamentals in software development. I am still firmly of the opinion that you need to have your fundamentals down solid, if you want to be a decent developer. However, several people made a valid point in response to that post, in that it is often difficult to know what the fundamentals actually are (be they macro or micro level). So, I thought it would be a good idea to do an ongoing series of posts on some of the things that I consider to be fundamental – this post is the first instalment.
Being a developer this day and age, it would be almost impossible for you to avoid doing some kind of web-related work at some point in your career. That means you will inevitably have to deal with URLs at one time or another. We all know what URLs are about, but there is a difference between knowing URLs like a user and knowing them like a developer should know them.
by Alan Skorkin on May 2, 2010
I love shell productivity hacks. I believe that if you work in a Linux environment, you owe it to yourself to become as good as you can be at working with your shell of choice (e.g. bash). You see, most people who have worked with Linux for any length of time have some level of skill with the shell, that level is usually mediocre at best. But, you do meet the occasional person who wows you with what they can accomplish and I will tell you right now that their skill does not come from superior knowledge (or at least not fully from superior knowledge). It is all about maximizing the effect of the knowledge you do have, finding little tricks and hacks that will save you, potentially less than a second, every time you perform a particular action. Thing is, some actions you might do hundreds of times per day, so those seconds really start to add up, especially once you have accumulated dozens of these hacks. Anyway, here is one such tip.
by Alan Skorkin on April 28, 2010
The other day something curious happened that made me question how I use bang methods (and their non-bang cousins). Here is how I normally look at using bang methods in Ruby. Always use the non-bang version, unless you have a really, really good reason not to. It just seems somehow safer this way, like when you're passing an object (String, Array etc.) around as a parameter, don't modify the parameter itself unless that is exactly the behaviour you're looking for. Use methods that don't modify the original object, but rather work on a copy, and then return the copy to the calling code. Maybe I am being too asinine about this, do come and let me know if I am :). Regardless, I have trained myself to avoid bang methods unless I really need them, but a few days ago I needed to merge some hashes.
You see, I had a file full of smaller hashes (serialized) that I wanted to read in and merge into one big hash. As usual, I tried using the non-bang version of the merge method and it just crawled. Let's recreate this code:
main_hash = {}
time = Benchmark.realtime do
(1..10000).each do |number|
simple_hash = {}
simple_hash[number.to_s] = number
main_hash = main_hash.merge(simple_hash)
end
end
puts "Time elapsed #{time} seconds"
puts "Main hash key count: #{main_hash.keys.count}"This produces:
by Alan Skorkin on April 27, 2010
I really hate it when managers refer to people (developers) as resources! I am not sure if this is an issue in other fields, but I do know software and it is rampant. Everyone is always concerned with resources.
"We're going to need more resources"
"Are you sure we have the resources?"
It really is hard to get good resources these days. The longer I spend building software, the more I find myself annoyed when I hear this talk of resources. Hardware is a resource, so is possibly computing power, certainly crude-oil; people are not resources!
Referring to people as resources, creates an impression that developers are plug-and-play components. Worse than that it makes it seem as if there is a readily available and inexhaustible supply of these "resources". Of course, these days we all know that even real resources such as oil, gas are not inexhaustible or as readily available as they have been in the past. But the attitude fostered by using the word remains the same.
by Alan Skorkin on April 22, 2010
The other day, during the course of my web browsing, I stumbled upon "The Raven" by Edgar Allan Poe. I love that poem, if you've never read it, go ahead and do so, it's a classic. For some reason I was feeling a bit creative at the time (that happens to me sometimes), so I decided to write my own version. Now, I know "The Simpsons" did a version of it, but that was for mass consumption, mine was going to be strictly for programmer consumption :). Anyway, I few hours later (many more than I would have expected, it a freaking long poem), I ended up with the following. Hope you like it (it really helps to read the original before you read this).
by Alan Skorkin on April 19, 2010
A large group of lumberjacks are cutting down trees in a forest and doing a really good job of it. Trees are falling left right and center, everyone is working with focus and tenacity. During a lull, one of the lumberjacks climbs up to the top of the biggest tree still standing and sees that in all the confusion to get the work started, they've made a bit of a mistake and should infact have been cutting down the forest next door to the one they're in. So, he yells down to the rest of the team:
Hey guys, I think we're in the wrong forest!
To which the foreman yells back:
Shut up! We're making progress!
by Alan Skorkin on April 18, 2010
A little while ago while writing this post, I came across the post by Jeff Atwood where he talks about the FizzBuzz test (originally found here). I remember seeing that post for the first time a couple of years ago and thinking that I would be a little insulted if someone asked me to write something that trivial in an interview. Seeing it again the other day I realized that my feelings hadn't changed. It IS an insulting question. Sure you may quickly weed out complete incompetents by asking it, by you will also alienate just about every competent developer. There is really no reason to ask a question that simple. You might as well ask something more complex, that could really test a programmer's skills. The incompetent will still have no chance, and you won't make the decent developers feel like you're making fun of them. If you can't think of any interesting programming questions to ask (and you don't like my quine question :)), I will try and cover a few decent, straight forward coding questions at some point in the future. But, that's not what this post is about.
