Favorite books
May 13th
I love to read. Every developer needs a few of their favorite books sitting on their desk for quick reference or to loan out. It always gives me pause to come across a developer that doesn’t have any books on their desk. One of my favorite interview questions is to ask a candidate to list a book they’ve read recently or to name a favorite author. You can learn a lot about a person based on the books they have read, which gives you more insight into hiring decisions. Recently, someone asked me about books I’d recommend for someone just getting started or in need of a Java/Dev refresher. There are a lot of great books for that situation, but these are some of my favorites:
|
![]() |
|
|
|
|
What job posting phrases really mean
Mar 24th
A bit of humor for the week….
| Challenging: | We fired the person that wrote all this junk and we need you to clean it up. |
| Self starter: | We won’t be giving you any direction, so it’ll be up to you to sink or swim. |
| Ability to prioritize: | You’ll have 6 projects to work on and they all are the most important. |
| Gets the job done: | You may be asked to do things that are immoral or illegal. |
| Team environment: | Everyone else has already formed a clique and you’ll be the outsider who gets the used PC and the crappy desk. |
| Fast paced: | We require a code slinging monkey hopped up on caffeine, which we’ll provide. |
| Flexible schedule: | We don’t mind if you take a long lunch because we expect you to work nights, weekends, and holidays. |
| Company first: | Resistance is futile. |
Interview the process
Mar 14th
I ran across a few interesting posts that somewhat go with mine on tech interview tests. First, Norman Richards, talks about the worst interview question ever while, Neil McAllister, talks about how you hire a developer. I’m glad other people are experiencing the same frustrations I have with the interviewing process. It’s mostly hit or miss walking into an interview cold if you don’t already have an inside connection. It almost makes serious networking a required skill for finding that next killer job you covet. I’ve found consulting has helped in that regard, but there are other things you can do from attending user groups, answering forum postings, working on open source projects, or anything else that gets you interacting with more people in a positive way. That’s not always easy for someone that sits behind a keyboard 9 hours a day.
On the other side of the fence, Mike Taylor, complains that programming is too easy while, Jeff Atwood, laments that he can’t find anyone that programs well. Which is it? It’s certainly not both of these. Mike is completely wrong when he whines that all programmers do today is glue stuff together while *real* programmers create everything from scratch. Attitudes like that completely smack of a not invented here syndrome. That just doesn’t cut it when your project deadlines are coming up and the feature creep sets in. It’s still and always has been about the customers and meeting their needs. Anything else is pure self indulgence. Meanwhile, Jeff Atwood, is trying to interview people by using a “pen and paper” style. While that method can work, I’d be afraid to disqualify someone good that isn’t adept at writing code on paper. That can be a difficult thing to do, when stressed, if you don’t do it often. At the very least, sit someone you’re interviewing down at a computer and walk through some code. Give them a taste of what they are going to actually be doing. The interview is your first and best chance to set expectations about what the job really is and what the work will be. It’s as much about them knowing if they are a good fit as it is you thinking they are. I’ve found most people are honest and will tell you if they don’t think they are a good match. They just need to be given that chance. If you can make your candidates a little more comfortable, you might be surprised at how much better they do. After all, the end goal is finding someone good to work with, not tripping people up on abstract or overly technical questions and yelling “gotcha” when they don’t produce the desired answer.
Input params are not for output
Feb 25th
Sometimes you run across some code that makes you cringe a little bit. That happened to me today when I ran across this blog post. It’s about how the final modifier is used for method parameters. A sample of what the post is trying to convey looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | public void printWords() { final List<String> words = new ArrayList<String>(); words.add("foo"); words.add("bar"); appendNewWords(words); System.out.println(words); } private void appendNewWords(List<String> words) { words.add("boo"); words.add("far"); } prints: [foo, bar, boo, far] |
The problem with that code is it treats a method input as an output parameter. Generally, that’s bad form and should be avoided. Even with a descriptive method name, you end up with code that doesn’t read well. A better example, with the input parameter removed, would look something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | public void printWords() { final List<String> words = new ArrayList<String>(); words.add("foo"); words.add("bar"); words.addAll(getNewWords()); System.out.println(words); } private List<String> getNewWords() { final List<String> newWords = new ArrayList<String>(); newWords.add("boo"); newWords.add("far"); return newWords; } prints: [foo, bar, boo, far] |
Perhaps you’re still dead set on passing your List object into a method and getting results back. Maybe you want to remove elements, for example. You still want to use input params for input and return an output object. In this instance, it’s nicer to pass an immutable List (Google collections) or an unmodifiable in and return results based on that versus modifying the input param, which leads to confusing code.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | public void printWords() { final List<String> words = new ArrayList<String>(); words.add("foo"); words.add("bar"); List<String> modifiedWords = removeFoo(Collections.unmodifiableList(words)); System.out.println(words); System.out.println(modifiedWords); } private List<String> removeFoo(final List<String> words) { final List<String> modifiedWords = new ArrayList<String>(words); modifiedWords.remove("foo"); return modifiedWords; } prints: [foo, bar] [bar] |
Trend Lines
Jan 30th
It seems we’re in a trend shift that’s deeper than has been experienced in the last several years. I don’t have any empirical evidence for this, but it’s the general direction people seem to be taking when I talk to them. Perhaps it’s a “something different” syndrome and most of these new technologies will never gain any mainstream traction. For my purposes, I’m dissatisfied with my current stack and actively looking to make some changes. Is anyone else feeling the need for a context switch to something different? What other products are likely to get dumped and become just a found memory?






