Tag: career2

How long does it take someone to learn to be good at building software in some language? I’m sure many of you have heard of the 10,000 rule that notes the truly gifted in a field need 10,000 hours of practice to become experts and master their craft. There’s some debate about how true that is, but certainly becoming an expert takes tremendous dedication, certainly years of time.

I ran across a piece that referenced a slightly shorter rule, the 100 hour rule. The rule is fairly simple: “for most disciplines, it only takes one hundred hours of active learning to become much more competent than an absolute beginner.”

One hundred hours is nothing. That’s a long week or two of active learning to get good at something. But how good? If we look at software development, what can you accomplish in 100 hours? After all, absolute beginner is a low bar. That’s the level my Mom is at and I’m not sure how much I could teach her beyond “Hello, world” in a few hours. Even in 100 hours, I’m not sure she could solve many problems.

The good thing is that most of us aren’t absolute beginners, especially in software. We have frames of reference for many parts of how computers work. I suspect that 100 hours of deliberate, guided, practical (meaning typing and practicing skills), would turn lots of people into a good junior developer, maybe even a mid level developer. I think many senior developers would be very competent in a new language in a few hundred hours, because they’d learn the syntax translation quickly and then start understanding the tips, tricks, and gotchas that experts in that language might know. The algorithms and problem solving skills are often the same between languages.

For most of us looking to grow our careers and improve our technology skills, I would guess we could learn a new skill every year, becoming competent, with 100 hours of practice. Reading books and articles is good, but the hands on practice is most important, and that’s what really drives home active learning. That’s something I’d encourage many of you do, with exercises, puzzles, or maybe even start a small project that help you learn. It will help your career, by improving skills, and might even be fun along the way.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

I heard Tim Ford say recently that the years of experience don’t matter as much as what you do with them.

That’s a great quote. It’s also one that goes along with the idea that there is no shortage of people that mistake 5 years at a job for 5 years of experience. It’s highly likely that many people really get 6 months of experience and repeat those same skills for years, because that’s what the job requires. Unless you have a dynamic, changing environment, one that experiments and regularly looks to upgrade systems, it’s hard to get those years of experience without changing jobs.

That’s a conundrum. Do you want to change jobs to get new experiences and grow? Some people become consultants for this reason. Others regularly look to move on to a new company, sometimes sacrificing benefits, short commutes, or something else to grow their careers. However plenty of people prefer to stick with an organization, whether that’s because loyalty, a great set of coworkers, security, or nature of the work being accomplished. Many people will stick with a job as long as they can.

In those cases, I do believe that you can still do something with your years and grow experience. Continue to learn, experiment, and suggest changes where they fit. Learn to write the complex T-SQL that’s needed in older SQL Server 2005/2008 systems, but spend a bit of time also learning how Window functions in SQL Server 2012+ run more efficiently. Rebuild reports in PowerBI, and see if your organization can see the benefits of investing in one new thing this year. Even if your company won’t make changes, imagine what you’d do if they ever change their minds.

Above all, practice your skills. Rewrite old processes and squeeze out more performance. Automate things in your job, whether you use PoSh or VBScript, when you can make gains in productivity, you can create time. Time that’s valuable in helping you learn. Even if you can’t get your code deployed, will will have the satisfaction of improving your skills, and knowing you can make a difference if you ever get the chance.

I realize many of you are busy. I realize that learning about R or Kimball data warehousing might be seem to be pointless because your organization will never use the technology. I get it, and I don’t disagree. However I hope to inspire you to try to enjoy technology. Jump on Twitter with the #sqlfamily and gain some motivation with what others are doing, or have them cheer you on as you learn. You might be surprised what you can do with your years when you find something you enjoy and get support from others that share your excitement about computing.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

This is probably a topic that is regularly debated in programming forums, but it’s still one that I think is worth revisiting regularly as our industry evolves. For those of us that write code, that develop software, are we engineers?

That’s the topic of a piece in the more mainstream media. It’s a bit of an attack on the software industry in general, noting that engineers are typically certified and regulated. They are subject to continuing education and apprenticeship. While certainly many of us continue to learn, it’s very informal, and not structured. Our education certainly isn’t certified in any meaningful way, though we often aren’t even really liable for our work. The cost of bad code is usually a job, with another one often easily found.

Engineering is defined as:  the work of designing and creating large structures (such as roads and bridges) or new products or systems by using scientific methods. By that definition, I think we are engineers. We use scientific methods, primarily the hypothesis, test, (usually) fail, change the hypothesis. The hypothesis we use are lines of code, which are often wrong and need work to get fixed. A additional definition includes: the design and manufacture of complex products <software engineering>. That’s us. Even the most trivial application today is likely seen as complex by layman. If most of us bothered to dig into the libraries we use, we might see them as very complex.

We certainly aren’t engineers in terms of the formal knowledge and liability that exists in our profession. There is little, often because we can fix problems quickly. Or maybe because even if our systems fail, issues can be undone by additional work. That’s not always true, but it does seem as though those systems which are costly when they fail (medical, financial systems), have some recourse available to those affected. Not always, but there isn’t always recourse in the analog world.

I wonder if we’ll get to the point where we require some evaluation or measurement of skills (or code) from software engineers for certain disciplines. My guess is not, as the world of software changes too quickly, and allows for too many different scales of acceptable performance to really certify anything. My guess is the world will continue to struggle with determining the liability and responsibility of software failure as we depend more and more on computing infrastructure in our world.

Likely this is an argument that will never end.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and LibSyn.