It’s not your code, but it is your opportunity

I occasionally hear the developer say “my code”, as in “I’ll check in my code at the end of next week”, or “My code doesn’t need unit tests”.

In one sense, I want developers to think “this is my code” so they take pride in doing the best job possible. But really, it’s not your code, it’s the company’s code – they’re paying for it, and often legally they own it (i.e. it would be illegal to take chunks of code you wrote at one company and either privately sell it, or check it into another company’s source code repository).

This perspective really changes the discussion, i.e. “The company would like their code to be checked-in on a regular basis”, or “The company would like their code to be properly tested”.

However, it is the developer's "opportunity to learn" – i.e. the company keeps the code, but the developer keeps the improved skill from writing that code.

Why I'm liking Pluralsight

My department had scheduled to send each of us to training. We had different training classes, and the specific vendor for my class needed to cancel. That left me short notice to squeeze in different training by year end. So, being creative, I got an online subscription to Pluralsight instead of the traditional training.

PluralSight is a set of online .Net videos created by industry experts.  Each video seems 2-4 hours' worth of power point slides and code demos. It's worked out very well. What I'm liking so far:

·         Different medium - After 10 linear feet of books, I like the different medium. Hearing someone's voice seems to trigger a different part of the brain for remembering, and seeing the demo from end-to-end has obvious benefits over isolated screenshots in a book or article.

·         It's on-demand – It's hard to make it to physical events. I like the inherent benefit of on-demand training, where I can listen on my schedule (by which I mean everyone else's schedule - my kid's sleeping schedule, my company's work schedule, etc…)

·         Professional content - There are tons of free videos online, but these are often like reactionary scraps. To break the ice with a new technology, it helps to have a systematic 2-hour block that goes from end-to-end.

·         Track progress – Some personality types won't care about this, but I like how it tracks completion progress through courses. It's almost like finishing levels of a video game.

·         Coordinated – I don't need 10 videos all telling different or rehashed angles of the same thing (which is often what I'd find in a google search) – rather I need one good video that nails it, or a collection of videos that each explains their specific part well.

·         Continually Improving – They seem to come out with a few new "courses" every week.

It's getting to the point where rather than watch my favorite sitcom, I watch the next Pluralsight video.

The exponential learning curve from studying off-hours

You work a full hard day, so why bother "studying" off-hours? Because, it has an exponential reward. The trick is to differentiate between daily "grunt" work that just takes time without improving you as a developer, vs. "learning" work, such as experimenting with new technology or patterns or tools.

I've seen endless resumes where the candidate says "I have 5 years experience in technology X", but it's really 1 year of experience repeated 5 times. They've sadly spent their career doing repetitious work, and have nothing new to show for it.

Here's a simplistic case: say you spend 9 hours a day ("45" is the new "40") at work, but 8 hours of that is grunt work – data access plumbing, fix a logic bug, attend yet another meeting where you just sit through it, fill out a timesheet – and you've snuck away only 1 hour to research some new data-performance prototype, that means about 90% of you day is grunt work, and about 10% is advancing your career. If you did 1 hour self-study at night, it's not that you go from 9 hours to 10 hours, but rather from 1 hour to 2 hours, i.e. that extra hour is "cool" stuff for self-study, so it gives your "self-study" a  100% return.

Because I love Excel, here's a chart. "Work hours" is split between "Grunt hours" and "self-study hours". Hence an extra hour or two at night could double your learning curve.

I realize this is very black and white, and live is grey (for example, our jobs aren't neatly divided into "grunt " and "self-study", and 1 hour of self-study may be split into a dozen 5-minute Google queries throughout the day), but the general idea still holds.

Work hours	Grunt hours	Self-study hours	Self-study Percent	Overtime Self-study	Self-study increase
9	9	0	0%	1	Infinite
9	8	1	11%	1	100%
9	8	1	11%	2	200%
9	7	2	22%	1	50%
9	7	2	22%	2	100%

Related to this is the Upward Spiral – that the extra hour of overtime helps you learn a technique that makes your day job much faster. For example, say you spend 4 hours a day writing plumbing code to filter C# objects, but then you study LINQ during the evenings and now can do a 4-hour job in 30 minutes. That theoretically gives you a "surplus" of 3.5 hours. Of course that time gets snatched up by other things, but in general it's reasonable to reinvest part of that time in yet further self-study, i.e.  compound interest for your development career.

Civil Engineering and Writing New Code

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/civil_engineering_and_writing_new_code.htm]

I have a special appreciation for civil engineering - I just find the bridges, highways, dams, and sky-scrapers beautiful in a way that an engineer can appreciate.

In America, before all the infrastructure was built, one might say that there was a "golden age" of civil engineering. With literally millions of square miles of country, there were seemingly endless opportunities to build new structures. And at the time that these structures needing building (before computers, flight, or bio-engineering), civil engineering was arguably one of the advanced fields of its day. You put these circumstances together: lots of new projects that require advanced technology - and you've got an engineer's dream.

Of course, over two hundred years, enough roads and bridges and buildings were built to fulfill much of the country's need. There were a couple spurts in between - building the highways, the major airports, an occasional monument, and more recently the cell phone transmission towers. However, in general, the civil engineering mindset went from "new creation" to "infrastructure maintenance".

At least from my perspective, the same life-cycle appears to be happening with software engineering. Even back in the 80's, just finding a machine, learning the syntax and writing a "program" was a new thrill. However, especially with the internet (just google the syntax and copy code-snippets), better hardware (you don't need an algorithm-genius to make an application perform), mass availability of machines, outsourcing (huge pool of developers), standard platforms and components that encourage reusability instead of re-inventing the wheel, and simply enough years passing - almost every established company has some sort of core IT infrastructure in place. Back in the late 90's, major companies had huge booms to implement their ERP, email, and websites (made lots of consultants very rich) - but now those expensive systems are in place. Sure, there's always work to do, like integrating components, migrating code, consolidating applications, extending functionality of existing apps, and maintaining existing code. There's still new development, but it seems much scarcer than 10 years ago. The cowboy days of just being thrilled to write a program seem to have passed.

Similar to how civil engineering has filled the country's physical infrastructure, software engineering has filled much of the country's IT infrastructure - and therefore in both cases much of the work currently being done is maintenance. America doesn't make many Hoover Dams or Golden Gate Bridges anymore - but there's always annual road re-surfacing. Same concept for developers. (This means that there's tons of legacy code out there, which is why every developer should read the phenomenal book Working Effectively with Legacy Code.)

Some developers view this in a pessimistic light, as if "the good old days" have passed us by. However, I'm an optimist, and there's much reason to believe that there are still many innovative and new software development efforts ahead.

• There are continually newer technologies - This provides a business incentive to rebuild older systems. Web systems replaced many fat clients. But now web 2.0 is replacing many existing web systems, and mobile apps may replace those, and there will be something after that (what if voice recognition takes off and makes most UI obsolete?).
• Much room for innovation - The nature of IT (with the low barrier to entry, the ability to cheaply experiment, and building projects out of "thought" stuff) allows for massive innovation, unlike any other field I can think of. Innovation means hopes for a better, more profitable system, and therefore business sponsors to fund new development.
• Software applications have a short lifespan. - Most software projects are replaced within 5-10 years, so there is continually new work. (A good bridge or building could last for a hundred).
• Programming is a foundational skill that can assist you with everything else - Because almost every desk job in any industry uses MS Office apps (or the equivalent of), databases, and web sites, the ability to write even simple programs can assist with those jobs. For example, writing an Excel macro or finding results in a SQL query may let you get a task done much quicker.

So while on one-hand there's definitely more maintenance work for all the legacy systems, as the field of software engineering matures, I think there's still a lot to be optimistic about for new development opportunities.

Thinking that you can learn it all

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/thinking_that_you_can_learn_it_all.htm]

I think .Net is too huge for one person to learn it all, and it's just getting bigger - like a galaxy. However, sometimes an optimistic developer may get the temporary delusion that they can learn it all, or at least the parts that matter. How could someone become so optimistic?

• Unexpected free time.
• Something came easier than expected.
• You're on a prestigious fast track project.
• A real good teacher explained something very well (and quickly).
• You're kidding yourself - you're just skimming, or only looking at buzzwords, not really digging into the tech.

Basically, if things are temporarily going well (i.e. you're absorbing new concepts really fast), it may be tempting to think that "ah ha, this learning thing has finally clicked, and it will always go fast from now on!" Oh, how I wish...

Why a manager may not want you to learn

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_a_manager_may_not_want_you_to_learn.htm]

I'm a huge advocate of learning. And it's natural for devs to want to pick up new stuff. However, many devs don't realize that they may report to a manager that actually wants to prevent them from learning new things - even on their own personal time. I think this type of manager is rare. However, it's good to be aware in case a manager is (perhaps unintentionally) "sabotaging" your learning.

I hesitated about writing this post lest it seem to cynical or jaded, but it's worth discussing as developers should be aware of such things. Note that there is not one specific person/event/incident that I have in mind, but rather glimpses of things over the last 10 years.

• Their control - They may want to be in control, and you learning new things that they don't know takes away from their control.
  • They may want to understand the entire architecture themselves. It's sort of a "not built here" applied to a personal level - "If I don't already know it, it must not be necessary."
  • They may not want to learn the new stuff themselves. If you're a tech manager, and all your devs learn the next wave of technologies, it pressures you to learn the new wave as well, else you look obsolete.
  • They don't want you exposing their mistakes. Say a senior developer wrote a bad messaging framework. As long as no other employee has a clue about messaging, no one knows that they made a bad mistake.
  • They want you to "suffer" just like they did. Often new techs make it easier to do something, and rather than have the easy way out, you should do it the original way so you "understand what's really going on". Think using assembly language or C++ instead of a higher-level language like C#.
• It doesn't support the immediate work
  • They may think it's a waste of time - "We've already invested in this architecture, we don't need anything else." Even though it's your own time, they'd rather you spend overtime on "useful features", like copying and pasting tedious code.
  • It competes with your day job - If you're researching some cool XNA technology, which is a lot more fun than the drudgery of some bad architecture, it may compete. Suppose you work at home, it might "distract" you.
  • It may be misapplied. New stuff is risky, and could be buggy or applied incorrectly - which would hurt the project.
  • Their afraid that "smart" developers are hard to manage. Smart developers can sometimes be total egomaniacs to work with (because they think they're so smart), and management may not want to even think about dealing with that.
• You may leave
  • You may outgrow your company and leave-  If your company is stuck in the dark ages, they may want to keep everyone's technical skills "in the dark" as well, lest an employee "see the light" and leave.
  • It makes your more marketable, and you may leave. If you're stuck with some niche technology on an obsolete framework, you aren't very marketable and hence can't get another job, and hence your boss has tremendous control over you.

Examples of how a manager might unintentionally discourage a developer from learning:

• Financially reject anything (like buying new books or tools or paying for a class)
• Undermine your confidence ("Why would you need that") or question your motives.
• Deny you resources, such as preventing you from installing anything on your machine (open source code, tools, etc...)
• Never affirm new learning or innovation. They tell you "good job" for getting that feature done, but won't affirm picking up new technologies.
• Never provide their software engineers with a continuing-education plan. Ask yourself, how do developers go "to the next level" in your team? Does management help them?

It's sad, but some companies are structured where it's not in the manager's best interests for the employees to "wise up". The managers want hard-working, honest people who are easy to manage, but they don't want to deal with innovation or smart developers.

LINK: Does your Project encourage learning

Why share knowledge with others?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_share_knowledge_with_others.htm]

I'm a big advocate of knowledge sharing. However, I understand why some developers may be hesitant to do so. We live in an era of unprecedented competition. People (and therefore Companies) compete against one another for employment opportunities, promotions, recognition, mindshare, and plain-old-power. In today's cut-throat world, it almost seems counter-intuitive to "undermine" yourself by sharing your knowledge (read: "competitive advantage") with others (read: "competition").

While obviously you shouldn't share trade secrets and proprietary knowledge with the competition, I still think there are a lot of good reasons to share general knowledge with the community, and especially your coworkers.

• It teaches you
  • Explaining something to others forces you to better understand it yourself.
  • It is self correcting - By sharing your knowledge, the other dev may be able to help you improve it by offering tweaks or suggesting gaps that you need to fill.
  • It provides a chance to practice your communication. To communicate, you need a "receiver", someone who wants to catch (i.e. listen to) whatever message you're "throwing". This means that the message needs to be relevant. What's more relevant than a message that is solving the problem that the "receiver" actively wants solved?
• Social benefits
  • To have a friend, you need to be a friend. If you never share your stuff (knowledge, tricks, tools), people may be hesitant to share their stuff with you.
  • Some people just enjoy helping others.
• It's part of your job
  • It frees up co-workers to do something useful (which could in turn benefit you, and more importantly, the company who is paying you), as opposed to them re-inventing what you've already done.
  • It's your job as a good developer - Good developers share knowledge. Also, when a company is paying you to code, it's no longer "your code", but the company's code, and therefore the company has a right that tricks and knowledge be shared amongst the team.
• Demonstrate leadership
  • Knowledge-sharing increases your credibility. By sharing objective things that other devs can verify to be correct, these devs are more likely to trust you on subjective opinions or predictions that are much harder to verify.
  • Become a thought-leader - Often consulting firms encourage their star consultants to demonstrate thought leadership by blogging, writing articles, or contributing to open source projects. Sometimes this is great marketing for that company, and even leads to sales. For example, thousands (millions?) of people use CruiseControl from ThoughtWorks, which in turn gives ThoughtWorks name recognition and marketing.
  • It is necessary in order to be promoted. Leaders communicate, and usually the higher up you go, the wider the audience you need to share knowledge with. If you never practice knowledge sharing until you absolutely have to (via a job demand), then you will probably not be very good at it.
  • It helps make your approach the official standard (which may be good or bad). If you hide your tricks and code, only you will use them. If someone publicizes and shares their code - even if it's worse than yours - their code will be used by more people and hence adopted as the "official" team approach.

There are many ways to share your knowledge, such as:

• Wikis
• Email
• Automated governance
• Sample applications
• Team meetings
• 1-on-1 meetings (like a Code Review)
• Blogging

 

The benefits of technical blogging

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_benefits_of_technical_blogging.htm]

By some estimates, there are over 50 million blogs. Granted, many of these are barely maintained, and they cover all topics (not just software engineering), but clearly there's something to this whole blogging thing. Keep in mind that the vast majority of these blogs are not profitable - so the authors are writing as hobbyists and not paid professionals. Millions of people - and thousands of software engineers - blog because there are a lot of benefits to it:

1. Record smaller thoughts to build up for a larger project like an article or even a book.
2. Instant gratification - Blogs let you publish your writing instantly, which is gratifying (as opposed to the lag time for an article or book)
3. Ability to share your thoughts with the world - and likewise get feedback on them.
4. Practice at writing, beyond just the quick email or IM context.
5. Provides an outlet for all the miscellaneous thoughts and code a developer comes across
6. Gets you to think deeper about ideas, knowing that you need to at least polish it to the level of a few paragraphs for public consumption. This helps you learn the topic yourself, as one of the best ways to learn is to teach the content to others.
7. Thought Leadership - some people (especially consultants where this is a resume credential) really like this. Good blog posts also build credibility.
8. Confidence booster - putting your thoughts out there to potentially millions of people requires courage, and repeatedly doing that (and growing from the feedback) builds confidence.
9. Write anything on any topic, regardless of what you're currently working on.
10. It helps others. For example, sometimes I post the most obscure syntax errors I find - and other people were troubled with the exact same issue, and actually find the post useful.
11. Blogging acts like a personal journal. I've gotten a kick out of seeing how some of my thoughts have evolved over the last 5 years.
12. Low barrier to entry - because blogs are (effectively) free, you can write small chunks, you can write anything you'd like, and you can automatically publish it, there's a very low barrier to get started.

Should you blog even if you don't get traffic? I think yes - if you enjoy it (such as for any of the reasons mentioned above). Traffic comes and goes, and the weirdest entries get tons of traffic while the other entries (that I expect to be popular) are almost ignored.

Related: Do you have time to blog?

BOOK: Pragmatic Thinking and Learning: Refactor Your Wetware

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_pragmatic_thinking_and_learning_refactor_your_wetware.htm]

I'm fascinated with learning how to learn, so I was excited to finally read Andy Hunt's Pragmatic Thinking and Learning: Refactor Your Wetware. Recall that Andy is one of the co-stars of the hit The Pragmatic Programmers.

This is a good example of a higher-level, "non-syntax" book, something that transcends the "How to program XYZ" genre. (Shameless plug: I had written my own book: A Crash Course in Reasoning, but I can see why Andy's is in the top 3000 Amazon sales rank, and mine is barely in the top 3 million).

My favorite chapter was "Journey from Novice to Expert", as there is such a huge productivity gap here. He also continually emphasized the differences between the two parts of the brain, comparing it to a dual CPU, single master bus design.

It was an enjoyable read, similar to picking desserts out of a buffet. He had a lot of good quotes throughout the book:

• "... software development must be the most difficult endeavor ever envisioned and practiced by humans." (pg. 1)
• "... it's not the teacher teaches; it's that the student learns." (pg. 3)
• "Don't succumb to the false authority of a tool or a model." (pg. 41)
• "If you don't keep track of great ideas, you will stop noticing that you have them." (pg. 53). This is huge. The "slow times" during the day (driving, waiting in line, burping a sleeping baby) are great for mulling over random ideas. It's almost like collecting raindrops. I used to do this, but got lazy the last few years. Andy's chapter inspired me to go out, get some pocket-sized notebooks, and start jotting down random thoughts again (read: future blog entries).
• "Try creating your next software design away from your keyboard and monitor..." (pg. 72). It's ironic, but often sitting in front of the computer, with all the internet distractions, can kill one's creativity.
• "So if you aren't pair programming, you definitely need to stop every so often and step away from the keyboard." (pg. 85). I've seen many shops that effectively forbid pair programming, so this at least is a way to partially salvage a bad situation.
• "... until recently, one could provide for one's family with minimal formal education or training." (pg. 146)
• "... relegating learning activities to your 'free time' is a recipe for failure." (pg. 154)
• "... documenting is more important than documentation." (pg. 179). The act of documenting forces you to think through things, where design costs upfront are much cheaper than implementation costs later.
• "... we learn better by discovery, not instruction." (pg. 194).
• "It's not that we're out of time; we're out of attention." (pg. 211)

Perhaps the best effect from reading this kind of book is that it makes you more aware, such that your subconscious mind is constantly thinking about learning.

What is the difference between an average dev and a star?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_is_the_difference_between_an_average_dev_and_a_star.htm]

Time and again, experience keeps re-affirming me that a star developer is far more productive than several average developers combined. It begs the question - what is the difference between a novice, average, and star developer? The naive thinking is that they're all the same kind, but they just vary by degree - i.e. that the star produces more code at a faster rate, with less bugs. But there's so much more than that. The star developer is a fundamentally different kind. Here's a brain dump of some possible differences between star developers and average devs (This also relates to the Dreyfus model of skill acquisition: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition).

A star developer:

1. Mitigates risk
2. Writes higher quality code
3. Predicts potential problems, and not design the app into a corner
4. Addresses performance, security, maintenance
5. Makes their teammates better
6. Comes up to speed quicker
7. Juggles multiple projects
8. Troubleshoots and figures out answers themselves
9. Does self correction
10. Handles non-technical constraints (like a political monkey wrench)
11. Can provide reliable estimates
12. Interfaces with non-technical folks (Managers, Business Sponsors); understands the business side
13. Throws away bad code; knows when to restart
14. Creates reusable code that helps others
15. Has influence beyond their immediate project
16. Desires to grow
17. Can work for longer periods without immediate and visible success
18. Can compress the schedule, such as doubling productivity.
19. Can coordinate other developers, even informally and not as a tech lead.
20. Can set up and improve process
21. Understands the concepts beyond syntax. Average devs crash when the technical road takes a curve with a new language; stars know the concepts and don't get thrown for a loop.
22. Knows when the rules do not apply
23. Knows where they want to go; can describe their career path.
24. Is continually learning and improving.
25. Can point to star developers and industry leads. If you're developing ASP.Net, and you've never even heard of Scott Guthrie, you're probably not a star.

Note that stars does not necessarily:

• Be perfect at everything. We all have some sort of limitations.
• Write perfect code --> we all make mistakes
• Have N years of experience
• Have external metrics (a degree or certification, a fancy title, got lucky with a well-paying project, etc...)

As a completely miscellaneous aside, I think of a real-time-strategy game like Age of Empires - what is the difference between an average unit and a star unit? Look at an average unit like a simple solder - it has basic properties like health points, attack, and movement. While merely upgrading the strength of these properties (more health, more attack, etc...) is great, it is still fundamentally missing other powerful aspects- the ability to heal itself, a ranged attack, the ability to swim (or fly!), the ability to collect resources or create buildings, etc... For example, a thousand normal AoE soldiers - which have zero ranged attack, and cannot swim - will never be able to hit an enemy across even a 1-block wide river.

How will you learn the next wave?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_will_you_learn_the_next_wave.htm]

New technology is constantly coming out. Some of these are small - a new tool, a special trick, or some open source library - and these can be learned easily enough. However, every few years, there's a fundamentally new wave of technologies that makes the previous wave obsolete. For example, classic ASP to ASP.Net 1.0, to ASP.Net (3.5 with Ajax, JQuery, and MVC) to Silverlight. - every few years there's a significantly more powerful UI technology.

So, the question becomes, how do you continually keep up with the next wave?

You have three main categories of options:

• Your company trains you. This was popular during good economic times. Some companies have a training budget based on a percent of the employee's salary.
• Your company doesn't train you, so instead you train yourself.
• You don't keep up, and eventually become obsolete.

The last option speaks for itself - but there's a difficult balance between the first two. Every developer should be able to ask their manager "What role, if any, does the company have in assisting me to learn the next wave of technologies?" Every manager should have a ready answer.

Realistically, you need both internal motivation and external support. For example, if your company won't even pay for a $30 book on a hot new technology, then you're screwed. On the other hand, you simply can't learn a whole new technology by passively skimming blogs during your lunch hour.

Personally, I'd emphasize the concept of an upward spiral. If you want to be a decent developer, be prepared to invest:

• Time - prepare to spend on average of at least 8-10 hours a week doing continual education. Maybe you're working 60+ hour weeks at your company, and the 10 hours is part of that. Maybe you have a "cushy" 40-hour week job and you do the 10 hours on your "free time". Sure, there are weeks (or even entire months) where life needs you to take a break. Likewise, there will be other times when an in-demand tech first comes out that you may be sprinting.
• People - Try to get to a live-person event at least once a year, such as a user group or conference. Also, explicitly seek out peers who you can collaborate with (even doing informal code reviews with your coworkers, or discussing ideas during a lunch break).
• Blogs - Use a blog aggregator to continually monitor the industry leader's blogs. This will give you a heads up of new techs coming down the pipeline, so you can prepare. If the tech actually has potential (as opposed to just some other buzzword), you'll see it light up on multiple people's blogs.
• Books - Especially for a new wave, or for matured design patterns on existing techs, try to read a full book at least twice a year (I think once every other month is more ideal, but there's a balance).
• Projects - If you have the opportunity, put in the extra work to get on a project that uses a new technology that appeals to you. Ultimately, the best way to learn a new tech is to actually use it, and unless you use it on a real project, you'll always remain a hobbyist.

Essentially, learning a new technology takes hard, pro-active, work, which many devs are already willing to do. The question becomes how to best maximize your investment on that hard work.

What makes a framework easy to experiment with?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_makes_a_framework_easy_to_experiment_with.htm]

I've been reading the excellent Framework Design Guidelines. One of the sections that stood out is the tips they offer to make your framework easy for other developers to experiment with. As most developers are experimental in nature, any framework must be "cooperative" in this manner in order to be popular.

• "Allow a developer to use it immediately, whether or not it does what the developer ultimately wants it to do or not" (23).
• "Types used in advanced scenarios should be places in subnamespaces" (23).
• "Provide simple overloads of constructors and methods" (24). A type that is hard to instantiate is hard to experiment with.
• Give common scenarios recognizable names. For example, "MyClass.CreateFile" sounds more friendly than "MyClass.OpenInputOutputSteam", so more developers would naturally experiment with the former.
• "...a default should never result in a security hole or horribly performing code." (26)
• "Do ensure that APIs are intuitive and can be successfully used in basic scenarios without reference documentation (27). I notice their emphasis - instead of writing tons of tutorials (which most devs won't even read), make the framework itself easy to use.
• Make things strongly typed.
• And the classic - A good framework makes it easy to do the right things, and hard to do the wrong things.

They offer ADO.Net as an example of what is confusing (juggling all the different types just to hit the database).

These are good points, and easy to overlook, but make sense when someone points them out to you.

What if you're a big fish in a small pond - life without a mentor?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_if_youre_a_big_fish_in_a_small_pond__life_without_a_m.htm]

In the ideal world, you'd work at a perfect company that surrounded you with wise mentors who could guide you past those insurmountable learning obstacles. Of course you'd work hard and take a stab at it first, but you'd know that an experienced guru would always be there to catch your back. But obviously, life isn't ideal, and many developers simply don't have that safety net of available mentors. Especially eager developers who work at small to mid-range companies might need to deal with being a big fish in a small pond. It's great that you can help your coworkers - but who is helping you? For example, I talk to a lot of guys in 5-person shops, and they're always the goto guy, always the one setting the path.

 

I hear it can get tiring. Here are some ideas to deal with it:

• Find others who are "bigger" - books, blogs, online forums, user groups. What's amazing about the internet (as opposed to 20 years ago), is that you can get access to all these brilliant minds out there.

• Leverage your coworkers niches. - Chances are, even with a 5 person team, the total-sum-knowledge of the entire team is greater than yours, i.e. someone there knows things that you don't. Maybe you're a star UI developer, but the DBA can teach you a few tricks. While this may not take you deeper in your own niche, it will help you spread out and be more well-rounded.

• Potentially leave your job - Sometimes you've out-grown your current job, and it may be time to "move on". For example, a lot of people go to industry leaders like Microsoft because they want that learning opportunities that a star company provides.

While it may provide a learning disadvantage to always be the one breaking-the ice, or drilling through rock to pave the path, there is an advantage. It forces you to pro-actively learn and demonstrate leadership skills, and a lot of companies (and life situations) value that sort of thing.

How to increase chances of being allowed to research

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_to_increase_chances_of_being_allowed_to_research.htm]

For any software project, there's always something new to research. Even if the flood of new technology suddenly freezes, most projects would still struggle just to catch up to the existing technology. While a lot of small to mid-size departments don't have dedicated research teams (or even tasks), here are some ideas to subtly incorporate research items into your schedule.

• Focus on small, concrete tasks that management cares about. A web app probably cares more about research JQuery or Silverlight than it cares about the WinForms DataGrid, or something ambiguous like "incorporating web best practices" (what does that practically mean?)

• Emphasize the low-hanging fruit with the highest return - Not all research tasks are equal. A SQL static code analyzer (which benefits everyone on the team) may be far more profitable than some crusade to make sure no-one uses Hungarian notation n C#.

• Piggyback off of existing assignments. If you're implementing an Aspx page, it may be the time to investigate Ajax, JQuery, or even something smaller like just JSON - you'd essentially have "the wind at your back". You could research an unrelated task, like hosting your  build process on virtual machines, but you'd be doing it all alone, without the support of your current assignments.

• Focus on just one or two things at a time. You could easily list 50 things to do - new technologies, tools, refactoring, open-source projects, controls to integrate, upgrading your framework, testing, automation, code generation, etc... If you juggle too much, it will all crash and you'll have nothing.

• Finish what you start; Actually deliver something - "A bird in the hand is worth two in the bush." For many departments, the thinking is it's better to have a weak solution that's completed (and hence usable - i.e you have something), than a powerful solution that's "still in progress" (and hence unusable - i.e. you have nothing.). The workplace is ablaze with buzzwords. Anyone can spew forth buzzwords or suggest grandiose visions, but at the end of the day - management cares about things that are actually done.

• Work incrementally - Management may initially not allot 4 weeks to research how Ajax benefits your web app, but you could spend a day here integrating it, a day there using an update panel, another day later pulling in the Ajax Control Toolkit. Yes, it's slower, but it's better than nothing.

• Establish a track record to "earn" bigger opportunities - As you gradually get research items actually completed, you'll become more credible, and will therefore probably be given more opportunity to research bigger tasks. For example, an unknown new-hire may be allowed to "explore" for a day, but a credible senior developer - who's already delivered many successful features - may be allowed to explore a research task for weeks.

You're not a real dev unless you've read this book...

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/youre_not_a_real_dev_unless_youve_read_this_book.htm]

Every now and then some amazing book comes out. And then comes people who insist that "you're not a real developer" unless you've read that book. I was reminded of this while reading reviews on Amazon for some of the hot books out there. While there are core competencies that every dev should know, there are also a lot of fringe topics, and multiple books on the same topic. And while a lot of these things are valuable, I think such an exclusive approach is damaging because it emphasizes not what you know and can apply ("can you write code with design patterns"), but rather what you've read.

 

For example, of course the GoF design patterns book is phenomenal. However, is it really that bad if someone read the C# translation of it instead (Design Patterns in C# by Steven John Metsker), or even skipped the books and went with purely online tutorials? I'd expect a "senior developer" to know what a design pattern is, recognize the buzzwords, and know how to apply them. However, if they got to that point from a different path then "normal" (?), I think that's okay. Part of the problem is that one cannot read it all, so it effectively encourages bluffing - developers buy classic books and display them on their bookshelf like trophies, and are afraid to let on about their shortcomings for fear of being rejected.

 

In short, I think it's far more effective to offer positive criteria like "developers on this team must be fluent in design patterns, automated testing, and writing clean code", as opposed to exclusive criteria like "you must have read book X".

Why syntax is becoming less painful

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_syntax_is_becoming_less_painful.htm]

Unless you're a language enthusiast, most developers dislike "wasting" time trying to understand syntax. Syntax trivia makes for bad interviews, developers dismiss a problem as "that's just syntax", and it's generally considered a waste of mental energy for developers to thrash over syntax.

 

Now, at least for the type of .Net application development that I often do, syntax is mostly pain-free, partly thanks to:

• Powerful IDEs that include intellisense and compiler checking.

• Billions of online examples that are a google-query away, such as complete reference guides, tutorials, forums, and fellow blogger's who encountered the exact same one-in-a-million bug.

• Better designed APIs. for example, both C# and VB.Net reuse the entire .Net framework, making syntax differences trivial.

• Emergence of standards, like XML, HTML, and language conventions.

• The deliberate attempt by designers and architects to reduce the need for syntax by wrapping interfaces with abstraction, using standards and patterns and reusable blocks, and leveraging config files.

• More developers in the field with whom you can ask syntax questions too. For example, I can often ask clear-cut SQL syntax questions to our DBA, and he'll just nail them. ("What's the syntax for setting an index on a temp table...?")

• More powerful hardware that lets you do all this. If you only have 4KB of memory, it's a challenge just to make something possible, and you're willing to throw easy-syntax overboard to get it to work. Your machine lacks the resources to "afford" an IDE, and every language construct is optimized for the limited resources as opposed to ease-of-learning.

However, it wasn't always this way. I remember as a kid back in the late 80's, with the TRS80 and RSDOS, just staring blankly at the green and black television (didn't have a monitor). There were a few "computer people" I could talk too (like my brothers), but it was nothing like today.

 

This comes to mind because I've been reading up on PowerShell and Silverlight, and it just works. I haven't had a major syntax problem yet. It feels like I'm just cruising down the highway, and that's a nice feeling.

 

The rewards from struggling to learn something

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_rewards_from_struggling_to_learn_something.htm]

In the movie Kingdom of Heaven, a knight, Godfrey de Ibelin, is instructing his son, Balian, about a sacred oath. At the very end, Godfrey slaps his son in the face and says "and that is so you will remember it [the oath]." The thinking is that people remember hardships. We remember when we've been wronged, certainly when someone slaps us in the face, and when we struggle to figure something out. The same thing applies to overcoming technical problems. When the computer "slaps you" in the face, you remember it. Maybe it's spending 5 hours for one line of code, redoing a huge component, or just throwing up your hands in despair, only to be rescued by an explanation from another developer. There's something about the struggle that really makes a lesson sink in.

 

Sure, of course there's no benefit to make something unnecessarily complex. Sometimes a technology is too new and unstable, and it's not worth the struggle yet. However, most work, will always require you to push through. Here are several benefits for pushing through the struggle to learn something:

• It teaches you to be the one who breaks new ground, especially for new or unsolved problems. As every new wave of technology comes out, all the cutting-edge developers (the MVPs, authors, speakers, top bloggers, architects, etc...) are working overtime to digest it, expand their brains, and work through the kinks. It is a constant struggle.

• It makes you truly understand the topic. If you just passively ask, you'll forget. If you actively figure it out yourself, re-deriving the algorithm or writing the code, then you'll get it.

• It makes you appreciate how hard it is for those "experts" to have the answers. Sure, some people are just smart and tough concepts come naturally for them. But most of these people are burning the midnight oil. The only reason that your local star can explain off the top of her head why you'll have a multi-threading error in your instance method is because she probably spent hours (when no one was watching) suffering through multi-threading bugs herself. The expert may be able to answer your question in 10 seconds - but that's only because they spent hours coincidentally studying it before hand. The coworker who goes around trivializing others' work ("Oh, that's just scaling out the database to multiple servers") is usually the one who's never had to do it themselves. They've seen others do it, so they know it's possible - but they think it's just another standard task.

• It spares you from wasting other people's time. Someone who always just asks other people the moment an issue comes up is wasting their co-workers time. If you haven't spent at least 1 minute googling it, you don't deserve to know it. Sure you can confirm your findings with others, but at least take a stab yourself. It reminds me when in a computer science class, a student posted to the forums asking "will 'int i = null' compile? " Obviously, they could have just figured that out for themselves by typing it in the IDE and trying - and it would have been a lot faster too.

• It encourages you to extend grace to others. Developer estimates are notoriously inaccurate. Often this is because developers come across an unexpected problem. If you're that developer, and you get burned yourself, then you understand what it's like when it happens to others, and you can be empathetic in a way that builds the team chemistry.

• It gives you experience with which to make your own code simpler for others. If you lost half your day tracking down a string case-sensitive error, you'll be sure to write your own code to be string-insensitive where applicable. Suffering at the hands of a poorly written component can guide you on what to do better.

• It's inevitable, so get used to it. The goal of a developer is to solve technical problems, and problems often entail a struggle.

Think of it like you're training for a marathon. Every struggle is a training session that builds up your perseverance, your endurance, and your respect for your coworkers.

 

I realize in today's "give it to me now" world, the whole point is to avoid struggling. And of course there's no benefit to struggle just for the sake of struggling. However, nothing in life - when you're actually the one doing it - is every just simple. People who do practical house or yard work see this all the time. "It's just tearing down the wallpaper" becomes an eight hour ordeal as you find yourself needing to steam the paper, tear it off shred by shred, scrape off the adhesive, and plaster in the gashes.

 

There's an old saying: "Anything worth having is worth fighting for." Without the guts to push through problem areas, you'll find yourself surrendering to every problem - and because the whole point of development is to constantly solve problems, that will forever block you from getting very far.

Why I still read technical books

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_i_still_read_technical_books.htm]

Occasionally I hear a respected developer make the case against books - "Books are dead, use other online resources instead." I acknowledge that technical books do have several limitations:

• They can be very linear, lacking the web's hyperlinks. While books can have cross references, but it's just not the same.

• Books are possibly outdated - books take an average of 1-2 years to get published. Especially with technical books, where the rush is to be first and "catch the wave", books on newer topics may be inaccurate because they were written using the beta of the technology.

• Books can contain information overload - you don't need every chapter in an ASP.Net book to get started (most developers never touch ASP.Net globalization).

• As a book is ultimately printed paper, you can't get a dynamic interaction from a book - i.e. stepping through a source code demo or seeing an animating demo.

• Books physically take up space, and can sometimes be very heavy, such as when you're a consultant in the airport and you need to pack everything into a single carry-on.

• Books can only be in one place at a time - so it can cause problems when you need it at home, but left it at the office.

• This is lame - but sometimes you're on a project where management discourages reading technical books during office hours ("we don't want the client thinking you don't already know what you're doing, read up on that stuff at home") - however the same manager is totally comfortable with you browsing online technical websites.

However, I think everything considered, there is definitely a time and place to use books as a learning resource. Some of these weaknesses can be turned into a book's greatest strengths:

• Books, usually a 200-600 page journey through a dozen chapters, are often more thorough than online tutorials or blog posts. They cover more topics, and show the bigger picture. This gives you a more proactive approach to the topic, as well as inevitably makes you more confident about that topic.

• Books are great for breaking the ice of a new technology because they are a step-by-step journey. You're not scrambling between misc blog posts or tutorials.

• Especially for general topics (basic Xml, Html, C#, SQL, JS), where the entry-level knowledge is pretty stable, a books provides a good introduction and guide.

• Because books are physical hardcopies, they're great when you just want to get away from staring at a laptop screen. Whether it's in an airplane (where practically there's not enough room to pull out a laptop), stepping outside, or even just taking advantage of 5 free minutes (good for reading a page, but barely enough time to even start up a laptop).

• For some personality types, books provide a physical trophy: "wow, look at all those books that I've read through."

Note that books are not intended to be used as your only resource, but rather as one part of a comprehensive learning strategy. Even most tech books today are filled with online links to demos, tools, reference guides, and community groups. I benefit a lot from reading books; I think they're a great tool in one's "learning arsenal".

 

The need and benefit of mentoring

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_need_and_benefit_of_mentoring.htm]

Most software applications today are just too big for a single person to handle, therefore projects are built by teams of people. Often these teams have junior members, and therefore it's essential to help these junior members learn and grow - i.e. they need to be mentored. Now sometimes it's an "emergency project", and there simply isn't time to mentor someone, but this is a dead-end approach. The successful, on-going projects are constantly mentoring the junior guys so that they have an every-growing pool of capable developers.

 

The beauty is that if you've got an eager dev, and you spend a few hours training them on a task or technique, then they can handle that technique going forward. This frees you up from that type of task, and lets you focus on higher level problems. In one sense, if you're to "move up", you need to ensure that the current class of problems you have are handled. You have a few options here:

1. Work lots of overtime, so that you're handling both your old problems, and the new one's you'll encounter at the new position. This approach isn't sustainable.

2. Make those problems go away, usually by solving them properly and simplifying the maintenance with automation. This is a good temporary solution, but ultimately the automation breaks, or the process itself needs to be modified, and then you get blindsided at the most inconvenient time.

3. Mentor someone else to take over your automated process. This is ideal. It involved other people on the team, and encourages that newly-mentored developer to understand and improve the process you original set in motion.

I personally find a good way to mentor people (and be mentored myself) is to emphasize the skills that they like and are practical to them, initially work with them one on one, then let them toy around with it on their own, then connect them with another person who can answer questions (your "backup"), while always keeping your door open to questions.

 

I've seen many senior devs, with good intentions, declare that they're "too busy to mentor people right now". Sometimes this is because the company only rewards immediate coded features, as opposed to long-term team growth, and a dev isn't jumping to do what they won't get rewarded for. Other times it is because the dev just doesn't know about mentoring - no one mentored them and they "toughed it out" the "old fashioned way". Still, other times it's because the senior dev is, to put it politely, being short-sited. As the saying goes: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life."

 

If you spend 4 hours ("but that's half a day!") mentoring a junior dev on how to fix security hacking issues, or use the new validation framework, and they then do those tasks for the next year, which saves you even 2 hours a week  - you've just been spared 100 hours. So, there are many benefits to mentoring:

• An hour of mentoring could easily give you 20 hours back - now that's a good return.

• There's a great feeling in helping others.

• Perhaps someday that junior dev will learn a technology that's new to you, and they'll return the favor.

• Teaching something to some else truly forces you to understand it yourself.

• It helps build a closer team.

I think because of all this, the best companies will always be actively mentoring each other.