I have been honored recently with an invitation to blog on the Los Techies website. If you like my technical blurbs of knowledge, come on over and subscribe to my RSS feed! In fact, why don’t you go and subscribe to the main RSS feed? The bloggers there are all much smarter than me, really.
http://feeds2.feedburner.com/LosTechies
I plan to keep this blog going with slightly less technical postings.
Thanks for reading!
A tingling sensation in the pit of my stomach, like a small flame that refuses to die as you turn off the gas… This is something I haven’t felt since my first days in college!
The passion for my craft and the pleasure I used to have at practicing it manifested themselves today. I’ve always known they were there, but for some reason they were hidden from my reach.
Through all the jobs I’ve had, I’ve yearned for that feeling to come back, that sheer joy of programming. I’m not talking about the exultation you feel when something that’s been bugging you finally works, like making an SSIS package work properly for example. No, I’m talking about loving the grind we all go through on a daily basis: writing lines of code.
I’ve been working on my behavior driven development skills and learning NHibernate today and it felt like I clicked. I was unable to write code before having written a spec and it eventually made me refactor in a few changes that made my code look… pretty!
I realized that I love doing well designed code. I thrive in such an environment and I’m able to enter the zone: spec-code-test-spec-code-test-spec-code-test… It makes me feel proud of what I did. I look at that big green bar and think that I can go home a happy man tonight. I’ve earned my diner. I feel like I went out of my cave and brought back a juicy mammoth for my family to eat. Aaarh! Something like that, anyway…
I don’t want to go back to my old ways, where passion had no room to expand and was all but extinguished! I shudder just to think of it. I don’t want to let go! I want to fan the flames.
“What design patterns have you used?”
This used to be the killer question for me at all the job interviews I went to right after graduating from college. I’d stumble and mumble, even though I’d studied them the night before, like with so many previous employers. You’d think that I’d know them by heart! All my poor younger self could do is say that he used the singleton pattern extensively and cross his fingers… It is obvious that what I lacked was practice. I’ve had to self-teach those skills over the years to overcome that deficiency.
Most job postings these days mention that you need some sort of expertise in Design Patterns. I deplore the wording, somewhat, since there are far more patterns than the ones depicted in the Gang of Four book. For example, Design Driven Development introduces a couple of new patterns, Martin Fowler brought in the Active Record pattern with his books on enterprise patterns and Agile practices have their own library of very useful patterns like Dependency Injection, which requires you to use the bridge pattern. This is clearly a fast evolving field where patterns now use other patterns! Having been an active learner in the past two years, I have yet to come across a blog posting on how to use that old bridge pattern. Instead, I see a lot of Dependency Injection patterns articles, or Inversion of Control tutorials.
Separating your implementation from the interface is simply a good practice now. Is it really still a pattern? Do we still need to call it a bridge? And what about dynamic languages like Ruby, where there is no need for such a separation? Some patterns are so trivial to use in some languages that we are using them without even thinking about it.
Patterns are tools that allow us to do our jobs more efficiently, which is why employers keep asking us about them. You plug-an-play them into your object model, tweak them a little, run your tests and voila! It works.
Have you ever used Linq to SQL? Then you have used the unit of work pattern. Do you practice test driven development or behavior driven development? Then you most certainly have used dependency injection to make your system under test work with your mock objects.
I’m also willing to bet my life on the fact that you have used the infamous singleton pattern, where only one instance of the object can exist. I’m also going to go so far as to say that unit testing an object that uses a singleton internally has caused you to cry yourself to sleep.
When you are asked which design patterns you have used in the past, the interviewer typically wants to know if you know your craft’s tools. He wants to know if you’ll spend days, and company money, banging your head against a problem that could be easily solved using a design pattern. Am I personally an expert in design patterns? Do I know them all? No. The important thing is to know they exist and how to use them, and the only way to do that is to stay alert and keep up with what your peers are doing. Of course, a little practice goes a long way, because when the pressure is up and a deadline looms, we all tend not to do what’s right.
In my last post, I mentioned I was going to use BDD and DDD to build a silverlight application. Well it took me a couple hours to settle on which BDD framework to use.
I started by trying out NBehave, but found it very verbose. I do not enjoy re-writing my stories in my tests. Stories should be defined, yes, but in a separate document. There is no point to repeating them again in the code.
Thus began a search for which framework I should try out. First, you have different unit testing frameworks, on top of which the BDD ones are built: nUnit, xUnit and MbUnit. Then you have a choice between xUnit BDD extensions, SpecUnit.Net, NBehave, StoryQ and mSpec.
Well, that wasn’t easy. In the end, I decided to go with SpecUnit, just because it was Scott Bellware’s project and he is quite vocal about what the others do wrong (see comments) and I’d like to see what he’s got to teach me with his framework. Yes, mSpec was greatly influenced by SpecUnit, but it is currently under development, so I’ll wait a bit before I try it. I guess the main point is that writing a few tests in SpecUnit was enjoyable, which is important if you’re going to be writing thousands of tests, I guess.
I’m going to Austin, TX in two weeks for a job interview where I’ll be asked to demonstrate my coding skills. Now, I’m the kind of guy who’s always humble about his talents. I mean, I grew up surrounded by people with mad hacking skills! They were doing object oriented programming, developing games and creating resident programs to allow us to use the mouse in the school lab when I was still trying to figure out how to program in Pascal.
Later, in College, those guys were rewriting C compilers, just for fun or putting in place a networked messaging system for their Quake-like gaming engine.
Great. I was having trouble balancing a binary tree in C++.
Okay, I’m selling myself a bit short here. After all, I did program a photon mapping engine and an image-based renderer. But we all know these guys. You know, like the one that created Linux in his spare time? These guys can make you seriously doubt your own skill set. On the other hand, they represent only 1% of all programmers so maybe I should really see how I compare to the other 99%. Well, not too bad, I suppose.
The key here is that they knew things I didn’t. They practiced when I wasn’t. So I’m a bit to blame here. However, I’ve recently taken back the “student” mantle and tossed it over my shoulders.
Here is a great article about learning and understanding. Go read it. I’ll wait.
Okay? Wasn’t that interesting? I mean, I knew practicing was part of the whole equation but I had never looked at the whole learning process like this before.
I’ve decided to put it into practice for the interview I’m going to. I’ve been reading a lot (and I mean *a lot*!) about being agile in the past two years without having the chance to put it into practice where I work. Well that changes now. I vowed to my interviewer that I would learn some Silverlight and show him what I can do. Thankfully, I’m already at the practice stage here since I’ve played with it in the past (a good thing for me since Scott Guthrie’s tutorials are a bit outdated and you’ll have to figure out a thing or two on your own.)
It might be backwards, but I’ve been mixing the learning stages a bit. For example, I’m reading the DDD book and creating domain models as I go, practicing without knowing everything. Same with BDD; I jumped into rSpec on a ruby on rails project without even knowing how it works.
I usually tend to jump into it and fight my way out. But this path can be frustrating to follow, with too much stuff on your plate all at once.
I’ve decided to build my Silverlight application using BDD and DDD, two subjects I’m currently studying intensely.
However, I will start by practicing the technologies and practices in isolation, so as not to be burdened too much. I’ve already been going through some Silverlight tutorials. Next, I’ll learn MbUnit and develop a domain model for my app with it. Finally, I’ll create the UI layer with Silverlight. I have 13 days, a wife and two kids. Can I do it and manage to impress a potential future employer?
I’ve just finished reading Never Eat Alone, a great book written by Keith Ferrazzi about networking and connecting with other people. I feel somewhat inadequate in this respect and I hoped I could gain a few good pointers from such a book. And I did! Living in the deep south of the Texas plains, I definitely need to grok networking to get further with my career.
The book was overall very useful. It is filled with techniques and examples of people who have successfully used them.
This is my attempt are summarizing the book.
You need to want to become a member of the club, somehow. Don’t be afraid! You want to hang out with the top dogs. In the end, who you hang out with kinda dictates who you are. Don’t keep score, be out there and help without asking for anything in return.
What is your mission? Write down your goals. It has been shown that you are more likely to achieve them if you write them down. Ferrazzi suggests detailing where you plan to be three months, six months, a year and three years from now.
You also need to build the network before you need it. This thing takes time! You need to have helped before you can be helped. So get out there and be audacious. Get in front of people and don’t be afraid to try and meet who you admire. CEOs and gurus are people just like you and I. As far as I know, they haven’t found a way to reach godhood, yet… But be careful not to be that networking jerk who tails people at conferences just because they said hi. Don’t hand out business cards without having first established a meaningful contact.
Do your homework. Research who you want to meet and find out what they like, where they hang out and with whom, and where you’re more likely to “bump” into them. This isn’t cheating. You did it for your girlfriend or boyfriend, didn’t you? Why should it be different for IBM’s CEO?
Whoever you meet, take their names and note it down. These people will be useful later. You’re expanding your network and everybody is worthwhile to know. Remember, you’re not out to abuse your network, you’re also there for them. One of these people will probably be the key to getting connected to somebody more important. They can be referrals that you can use when cold calling your idols, which makes it not-so-cold anymore.
Speaking of cold calling, befriend the secretary or personal assistant. They can become powerful allies. Did you know they can actually influence the person you’re trying to reach? Yeah. They can.
Take your people out to lunch, share your passions. Keep developing the relationship and strengthening the bond. Invite somebody else you know to your lunch and be a connector yourself! And when you meet new people, follow up before they forget about you. A gentle reminder of a meeting in an email, simply saying thanks for a great time or just saying hi will work. You want them to remember your name the next time you talk to them.
Be a conference commando. Go to conferences to network. Research who will be there and plan on “bumping” into them. Learn who is organizing the whole thing and volunteer to help out. You’ll meet a lot of people that way in addition of getting a heads-up on who’s coming. Also, try to be a speaker.
Connect with connectors and marvel at the power of crossing the streams. I don’t care what you learned in Ghostbusters, crossing the streams is a good thing when mixing networks together. But there are rules. Don’t give away your entire network all at once, because the other won’t. And don’t make your connector friend look bad with their network.
Always work towards expanding your circle. Find ways to meet new people at all times. Master the art of small talk, which can be hard. Try listening to local talk radio. You'll have some stuff to talk about. It also help if you know what the other person is into.
Health, wealth, and children. Those are the three things people really care about. If you can help somebody with any of those, you’ve just made a friend for life. Can you get that guy’s kids into the best college in town? He’ll be forever grateful. Or did you refer that gal’s daughter for a very coveted position that just opened up in your organization?
Connect people together. If you meet someone who needs something and know a friend who can provide it, please connect them. Learn more about arbitrage here.
Ping your contacts constantly. You don’t want them to forget you. Depending on how close they are to you, ping them monthly, semi-annually or annually. When you travel to their area, give them a call. Try to meet face-to-face.
Organize diner parties and invite anchor tenants: people with certain influence that keep coming to your parties. Almost by magic, other people will want to be there too.
Be interesting and build your brand. You have something to say and shouldn’t keep it to yourself. Form opinions, ideas, philosophies. Don’t be average. Stand out! Then broadcast your brand. Shout it out. Blog it, write guest columns, talk in conferences.
Get close to power by meeting assistants or people close to who you really want to meet. In gatherings, the important people will typically be extremely busy, while their aids will stand idle. Meet the aids! Again, we are not out to use them. We really want to know them.
Build a network that people will want to join, but don’t become arrogant or you’ll kill the golden goose. Find mentors who can teach you and mentees who will learn from you.
Finally, welcome to the connected age! Use LinkedIn, Twitter, blogs, FaceBook, Plaxo, etc. Connect!
