Our team is comprised of 3 dedicated developers, 1 project manager, 1 super dedicated product owner and a trusty task board. Although, we're a small team we've been uber successful, and so far have been able to out perform the competition (in a surprisingly short amount of time).
One of those reasons is because of how "tight" (read:close) the team is. What I mean is that we're completely open with each other, which has allowed us to really gel as a team. We have our good days and bad days, but overall I feel like I can honestly depend on my team mates, and likewise.
We all make the same salary, and have the same amount of shares. There's no super heroes on our team. We all have strengths and our weaknesses, but there's no sense that any one of us feels like we are obligated to outperform one another. We're judged based on team performance rather than individual performance.
"The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?" - Kent Beck from Extreme Programming Explained
Depending on the day, we each step up to lead the team. There's no water cooler discussions about why a member of the team makes x dollars, while I make x - 20K. We're either performing or not, and call each other out when we're not.
So far, this has helped our team gel. I'm curious to hear how about why you and your team are so "tight"?
So JP had to tag me... then the Los Techies crew had to invite me to join Los Techies. This sucks for someone who "claims" to be quite a private person. Thanks JP for putting me in the spotlight, and thanks to all the techies who thought I was fit to join. So here goes...
How old were you when you first started in programming?
I was in grade 11, so I guess that would have made me 15.
How did you get started in programming?
Hmm... Kind of by accident. I took a C++ course in high school as an option and I found that I actually liked it. I didn't actually think I was capable of becoming a software developer, but I knew I liked it.
What was your first programming language?
What was the first real program you wrote?
In college I signed up for a curriculum that focused more on electrical engineering than software development. However we got a little bit of exposure with different programming languages like assembler and C.
The first actual program that I finished was in my second year of college. We wrote a piece of voice recognition software using MatLab. It was actually a tonne of fun, because it required us to utilize what we had learned about digital signal processing as well as how to pick up a brand new language and learn how to get something compiling with it in a short bit of time. This was probably when I realized I liked staring at code more than I liked staring at circuit diagrams.
What languages have you used since you started programming?
Assembler, C, C++, C#, T-SQL, VB, VB.NET, MatLab. The languages I would say I'm ok in are C and C#.
What was your first professional programming gig?
Right after college I got scooped up by a company called DataShapers, where I got to work on a project called Incentus. It was a Gift Card, and Loyalty Management system. I was hired to build embedded gift card applications for different point of sale terminals.
I was quite fortunate that I got to work on such a sweet project right out of school. I was exposed to things like chip cards, 3DES encryption, SSL/TLS at a raw sockets level written in C. I was fortunate enough to be mentored by one of the best while I was there. Thanks Mr. Mark!
If you knew then what you know now, would you have started programming?
If there is one thing you learned along the way that you would tell new developers, what would it be?
Actually listen to your elders, and follow through with what they tell you. At the same time, question everything they tell you, and decide what's right for you.
"Listen to your elders, but question everything they tell you."
What's the most fun you've ever had programming?
The Nothin' But .NET boot camp (times 2)... seriously, it blows my mind!
Who am I calling out?
Adam Alinauskas (whenever he gets his blog back up)
So yesterday I had this idea on how to run a background thread using an interceptor, but first I needed to Grok how the castle interceptors worked. I quickly ran into a snag, it looked something like this:
The problem is that the latest version of Rhino.Mocks hasn't internalized the castle dependencies. So the compiler doesn't know whether I'm referring to Castle.Core.Interceptor.IInvocation from the Castle.Core.dll or Castle.Core.Interceptor.IInvocation from Rhino.Mocks.dll.
I'm not sure why this is, so I did a little digging. And found this post... In one of the last comments someone else had this same issue...
I'm not really sure what this meant, so I decided to pull the source from the trunk. In the Rhino.Mocks project there's a file called "ilmerge.exclude" and in it was the interface that I was having trouble resolving (IInvocation). I removed it from the file, and rebuilt a release version. Seems to be working now.... I'm still not sure why this change was made... which makes me feel a bit uneasy.
Try it at your own discretion.
In case you haven't you should read...
As a reminder, let's talk about a test smell described in the above mentioned book. It's called "Conditional Test Logic".
"Conditional Test Logic: A test contains code that may or may not be executed." xUnit Test Patterns
"A fully automated test is just code that verifies the behavior or other code. But if this code is complicated, how do we verify that it works properly?"
Warning bells should sound off in your head when you start to see looping or conditional constructs within a single unit test.
"Code that has only a single execution path always executes in exactly the same way. Code that has multiple execution paths presents much greater challenges and does not inspire as much confidence about its outcome."
For more information check this out...
Basically Ignore Logic... that could cause multiple execution paths within a single unit test.
So I got a phone call this morning that went something like this....
"Yo mO, what's happenin' homie?", voice on the phone.
"Ye'.... I'm just slingin some code wit my compadre, G. What's crackin'?", says mo!
"So word on the street is that you're slingin' some made Rhino Mocks 3 dot 5 ish? So lemme asks you, how do you bust out some event raisin' with the new ish?"
My response... "I gots no clue my man, no clue!"
After some quick digging here's what I found... (Please remember this is a contrived example!)
The old school way...
Here's the new way.. that I quickly Googled for...
So there you have it. Enjoy..
I found the usage on Ayende's wiki here. Also, I am not a Rhino.Mocks guru, nor do I want to be, and yes the phone conversation was not as interesting as was previously illustrated.
Building a splash screen. (err... not taking a bath)
So one requirement we had this week was to add a splash screen to the project we're working on. My knowledge of threading is weak, so bare with me. As our application started to grow, the start up times started to grow so a splash screen is supposed to be a queue to the user that yes the app is running.
This is what the end result ended up...
So what's happening is the Splash screen is loaded on a background thread, while the application start up continues on the main thread. When the application start up is finished, the background thread disposes of the command that it's executing. In this case it starts fading the splash screen away.
Here's the core interface that made this happen.
This is a pretty simple solution (IMHO). The actual splash screen is just a win form, that starts a timer and adjusts the opacity when it's asked to display, then fade away when it's asked to hide.
For starting and running a non-blocking background thread, we're using the BackgroundWorker class which takes care of thread synchronization. (This comes in handy for synchronizing UI elements)
Just so you get the rest of the code, here's the DisplaySplashScreenCommand, although I'm sure it was obvious.
Hope this helps anyone out there trying to implement a splash screen. PS. I can't stress the fact that my knowledge of Threading is limited, so if you know of a cleaner implementation... Please, please hook a brotha up!
The end result looks like...
Tonight I finished reading...
This was an amazing book, and definitely offers a great in depth look at the C# language. Most importantly it answered a lot of my questions about elements introduced in C# 3.0, and taught me things I didn't know about C# 1.0. If you're looking for information on the following items, then this book is definitely for you.
- Type Inferencing
Thanks JP for recommending this book!
Here are a few gems that I picked from this book.
"You rarely see an explicit call to Delegate.Combine in C# code - usually the + and += operators are used."
Static vs Dynamic Typing
"C# is statically typed: each variable is of a particular type, and that type is known at compile time. The alternate to static typing is dynamic typing, which can take a variety of guises. "
Explicit vs. Implicit Typing
"The distinction between explicit typing and implicit typing is only relevant in statically typed languages. With explicitly typing, the type of every variable must be explicitly stated in the declaration. Implicit typing allows the compiler to infer the type of the variable based on its use."
Covariant vs. Incovariant
Jon, the author, mentions a blog post by Anders Noras on Planning a fluent interface
Here's an example of a fluent interface for building menu's that I've been playing with.
"When it comes to getting the broad sweep of code, what is required is 'readability of results' - I want to know what the code does, but I don't care how it does it right now."
There's a lot of information on IQueryables, Expression Trees, and other goodness in this book. This is a great book and definitely worth reading, especially if you're as interested in the C# language as I am.
I mean Grokking Rhino Mocks. My usage of Rhino Mocks has changed quite a bit since I first started using it a year ago, as well as the way I write tests.
First it was like this:
Then it evolved to this...
Then for a short time I tried this...
Now I'm trying this...
Now I'm generating reports from my
tests specs using this. I wonder what's next...
Last week I finished reading...
I really enjoyed this book, it's definitely worth taking the time to sit down and read. I realized a lot about myself as I read it. Hopefully you will too! Here are a few excerpts from the book that had an impact on me.
"Management is a bottom line focus: How can I best accomplish certain things? Leadership deals with the top line: What are the things I want to accomplish?"
"... envision a group of producers cutting their way through the jungle with machetes. They're the producers, the problem solvers. They're cutting through the undergrowth, clearing it out.
The managers are behind them, sharpening their machetes, writing policy and procedure manuals, holding muscle development programs, bringing in improved technologies and setting up working schedules and compensation programs for machete wielders.
The leader is the one who climbs the tallest tree, surveys the entire situation, and yells, 'Wrong Jungle!'"
"Work Centeredness. Work-centered people may become 'workaholics,' driving themselves to produce at the sacrifice of health, relationships, and other important areas of their lives. Their fundamental identity comes from their work - 'I'm a doctor', 'I'm a writer', 'I'm an actor.'
Because their identity and sense of self-worth are wrapped up in their work, their security is vulnerable to anything that happens to prevent them from continuing in it. Their guidance is a function of the demands of the work. Their wisdom and power come in the limited areas of their work, rendering them ineffective in other areas of life."
"There are times when neither the teacher nor the student knows for sure what's going to happen. In the beginning, there's a safe environment that enables people to be really open and to learn and to listen to each other's ideas. Then comes brainstorming, where the spirit of evaluation is subordinated to the spirit of creativity, imagining, and intellectual networking. Then an absolutely unusual phenomenon begins to take place. The entire class is transformed with the excitement of a new thrust, a new idea, a new direction that's hard to define, yet it's almost palpable to the people involved."
"Suppose you were to come upon someone in the woods working feverishly to saw down a tree.
'What are you doing?' you ask.
'Can't you see?' comes the impatient reply. 'I'm sawing down this tree.'
'You look exhausted!' you exclaim. 'How long have you been at it?'
'Over five hours,' he returns, 'and I'm beat! This is hard work.'
'Well, why don't you take a break for a few minutes and sharpen that saw?' you inquire. 'I'm sure it would go a lot faster.'
'I don't have time to sharpen the saw,' then man says emphatically. 'I'm too busy sawing!'"
"Principles are natural laws that are external to us and that ultimately control the consequences of our actions. Values are internal and subjective and represent that which we feel strongest about in guiding our behavior."