1. Logic for budget accuracy calculations (just a method right now, no actual implementation on the site yet)
2. CRUD for recurrences (and a slick interface to boot—I’m really enjoying working with these DevExpress controls)
3. Account balance projection chart

So, that leaves the following stragglers on my to-do list before the first release (likely to be labeled an alpha—not all features are there, not everything works):

• Actual implementation of the budget accuracy calculations (displayed as % error)
• Logic/implementation for budget adjustment suggestions
• CRUD for manual entry and adjustments
• GUI work
• Data export
• Wizardry for new users to introduce them to key elements of the app

I’m really excited about where things are going with this project, to the point that I don’t think the Windows version of this project is going to be able to keep up with all the great features. I’ll tune in again next Thursday at the latest for another update on this (probably sooner). I should have some real web hosting by then, so I’m pushing hard to get a release out in the next two weeks.

1. Worked out web and data hosting (thanks boss). GoDaddy just doesn’t give me enough control over things to go that route with any real web applications (although they’re great at hosting this blog!)
2. Decided on some controls I’m licensed for through work. They aren’t free, but if you want to debug through any source code I make available you can install a trial. I decided quality was more important than making the code super easy to share in this case.
3. CRUD finished for accounts.
4. Some back-end work done on recurrences/transactions.
5. Balance calculations are working.

Immediately next on my list are:

• Logic for budget accuracy calculations (this one’s a new idea)
• Logic for budget adjustment suggestions (based on the accuracy calculations, also a new idea)
• CRUD for recurrences/manual entry/adjustments.
• Account balance projection chart
• More time spent on GUI design
• Data export functionality
• Process to drive new users to the most useful functionality right away so they see the real benefits over time (following the visualize, control, predict pattern):
• Set up an account with recurrences to visualize the current state of the account
• Use transactional adjustments to correct the budget with actual figures
• Modify budget (recurrences) based on suggestions (control)
• Using an established budget and calculations based on the average error margin, allow the website to predict the most accurate balance curve possible over the next year

Me: “How does the car go?”

Mom: “I press the gas pedal and it goes.”

Me: “What does the gas pedal do that makes the car go?”

Mom: “I don’t know, ask your father.”

I probably had 5-10 conversations like that per day from the age of 3 until the age of 12. I was (and always have been) thinking about the details.

I define seeing the details as being able to look at something and dissect it into its smallest parts. This is a valuable skill for any programmer, and, I believe is what separates people who should learn to code from those who might be better off avoiding it. I had far too many classmates who were in it for the money, but had no passion or thirst for understanding. That drive is a key determining factor about someone’s future in software development. Seeing the details in my job means being able to mentally translate an assignment into code, including all the edge-conditions, so I can accurately estimate how long a project will need for completion. Seeing the details means being able to predict potential problems in January while the team is planning instead of getting caught off guard in June while we’re coding. It even means not writing the bugs other developers might. Yes, seeing the details is a valuable skill in software development, and I don’t see that changing anytime soon.

I never was a big picture kind of person growing up. I made passable grades on my papers in school because I could make really wonderful points, but I had trouble making everything from the first sentence to the last cohesive. Instead, my papers ended up often containing a few somewhat related ideas with an underwhelming effort to tie them together. As it turns out, while seeing the details is an important skill in software development, the converse is equally true; being able to let go of fine details and see the big picture is necessary for anyone who is more than just a code-monkey.

I define seeing the big picture as being able to look at something and understand not just how it can or does work, but how it could and should work. Seeing the big picture also means being able to look at something and understand how it should coexist and cooperate with other things. This is a valuable skill for anyone who wants to be more than a programmer. It separates people who should get a coding job and just take their annual pay increase from those who should attempt to scale the ladder.

I really believe that to be a truly successful leader in software development both of these skills are a must. One or the other just won’t do. Those who can only see the big picture can be great managers of small or open-ended projects, but without being able to see the details a project manager must rely on his developers to understand what a project will cost. Alternatively, those who can’t see past the details are wonderful programmers, but without seeing the big picture a developer must rely on his manager for direction. In my opinion, someone who has both skills can be a great leader and an invaluable asset, adding efficiency to an entire department.