Education paths for tech workers has been pretty cut and dry for the past few decades. Get through high school and ideally be good at math, then move on to a university and major in computer science, or computer engineering, or some type of mathematics. Alternately, go to university and major in the humanities and spend a lot of time with learning on your own after graduation while working your day job.
There are a few problems with this model though. Most software jobs don’t require a deep understanding of pointer arithmetic and data structures. After graduation, most of us will spend your days writing web-apps that help with some business process. I don’t mean that as a bad thing, at all, there is a lot of value there which is why this is such a big part of the programming world. So, you spend 4 or 5 years learning the most intimate details of software development and may rarely have an opportunity to use that knowledge.
(I have a hard time learning in this environment, do you?)
Expense was a big problem for me, I bet others have shared this experience. A university diploma isn’t cheap and it is growing more and more difficult to justify for a lot of people. I spent about 10 years on my undergrad working full time as a way to offset the cost. Each semester I took one or two classes and paid in cash. While taking one class per semester, the industry work experience I was gaining quickly became more valuable than the degree I was working on. I knew something was up, but there that nasty rumor that you will never advance without a degree kept looking my way.
There are quite a few non-traditional school options around that are probably worth exploring if you find yourself questioning the university route. Job specific schooling can be a great alternative for people who don’t fit well into a university system, or people that are already in the workforce but are looking for a change.
Tech schools range from the extremely casual to an intense boot camp type atmosphere (sans push ups I suspect). On the more casual side of things are websites like codeschool.com where a student can register and work through a series of exercises based on the technology they want to learn.
(Nashville Software School graduating class)
The goal of this program is to teach technologies that there is local market demand for, and to help the students land a gig as soon as they graduate. From what I understand, they are doing a pretty good job at both of these things.
If you want to build software for the space station, or for geological drilling expeditions, sure, go get that university degree. But if you aren’t set on that, you may want to consider some vocational options.
Next time I’ll be talking with a friend and instructor at Nashville Software School to get a closer view of how they do things.
Steve Wozniak is the other founder of Apple Computer Corporation, the one who actually built the Apple I and Apple II. Many of us know that ‘Woz’ left Apple quietly in 1987, for several reasons, one being the realization that in their early partnership to create the Atari Game Breakout. (The two were to split the fee. Jobs collected $5000, and gave Woz $350; Woz would not find out for over a decade.)
Despite the breakup, Wozniak has been quiet about his feelings about Jobs. It might have been out of loyalty to Jobs, or to Apple Computer, or, perhaps, Steve Wozniak just isn’t the kind of person to make a mess in public with no clear benefit to anyone.
All that changed with the new movie, Jobs, starring Ashton Kutcher. Suddenly there was a new narrative about the founding of Apple, one without Steve Jobs around to make corrections.
It was time for Steve Wozniak to set the record straight, and to do it, of all placed, on a public comment to a Google+ post. Continued »
It looks like Zappos is joined the company wide reorganization bandwagon, but this time it has a new name; holacracy. This new change will mean fewer managers, fewer or no job titles, and small empowered groups working together to solve problems. Gone are the days of working through a red tape to get permission to do work.
When reading about this, I can’t help but think that this is completely in the spirit of the agile manifesto. In the agile world, everyone is a developer. Everyone focuses on the product and what actions can be taken to ship software and ship it faster.
Fred George refers to this phenomenon as programmer anarchy.
Back in the day, I worked at an early stage start up in a previous life that had a fair bit of success with this. We were building a software product, trying to get to market as fast as humanly possible to see if the customer would like it. If the liked it, great! If they didn’t, we would do the same thing but different and see if they liked the new different. Failure was quick and changing directions was no big deal.
Slowly, this little infant of a software project turned into and adolescent. The project had grown quite a bit, the team had grown a little bit, and most importantly we had paying customers. Paying customers that don’t like failing software. Releasing multiple times a day became dissatisfying for customers that like some amount of stability.
We did have managers, titles, and team members self-identified with certain parts of product development that they enjoyed or felt comfortable with.
As far as I can tell the mistakes that lead us to be not holocratic (and not very agile) were having paying customers, and a product that eventually became monolithic. One of those seems to be negotiable though. I mean, Facebook and Google seem to do just fine with monolithic software.
Many times, this structure can lead to customers being used to vet new ideas. Facebook doesn’t exactly have an untarnished record as far as releasing quality software goes. I’m sure you see the complaints and reports of weird behaviors in your feed each time they push a noticeable update. The theme for holacracy seems to be mediocre software as fast as possible, then something different is customers complain loud enough.
I wonder how this will work out for Zappos.
If you want to start a fight on my team, bring up estimates. Just the idea of estimates is a “hot button issue”, and I don’t think it’s just my team.
On any given team, the technical staff are likely sensitive about how their estimates will be used. They have reason to be sensitive; there is a system-wide cultural misuse and misunderstanding around the concept. Woody Zuill is trying to reframe the estimates discussion around the idea of starting and completing small pieces of work, and not estimating at all. You can follow that by looking at the #NoEstimates hashtag on twitter. Matt Heusser, the lead contributor to this blog, did some investigation and wrote an article recently for CIO.com about transitioning from traditional planning and estimating to, well … not.
Let’s consider another case: What if the act of estimating tasks actually has value?
If you are willing to grant that, then we can explore ways estimation might be a useful exercise for you.
(kanban board: how much work goes here sometimes depends on your estimates)
My ideas on estimates:
Estimates can be used for all kinds of things: accounting and billing, planning what can be completed in a sprint, and, yes, as a whip to punish people who can not comple work they have “committed” to complete. I’d be willing to bet you’ve experienced each of those at some point in your tech career. One thing I think we ignore though, is the way group estimates can take the ideas (and variances!) in our head and bring them out to the table where we can talk about them for real. That’s a meaningful benefit. Since estimates aren’t going away anytime soon for most people in software, that’s what I’d like to focus on: The benefits.
Pretend you’re in a meeting to plan a some work for the next two weeks. (If you are a scrum-er, this is “grooming the backlog for the next sprint.”) You all talk about a feature for a bit, what this thing should do, how users might benefit from it, and think you understand it pretty well. At least to the extent that you can start to make some guesses about how complex you think the work to build this feature is.
This conversation takes place:
PM: Alright, does everyone think they understand this enough to make an estimate?
PM: OK then, lets do this in t-shirt sizes. 1…2….3….go!
I think this difference is really important and is something the no estimates community doesn’t talk about enough. Sometimes estimation differences means people have different skills on the technology, the code base, or even a different understanding of the problem to be solves. Sometimes they are a lesson in disguise. As a general rule, if your technical staff have wildly varying opinions on how long something will take, then something might be going on there worth talking about. This might not tell you where to look or immediately solve a problem, but it sure seems like a good start.
This difference in estimates can be a clue that people have different understandings about what they need to work on. Maybe there is a complete misunderstanding about what is being built, maybe someone knows about available libraries or utilities that you don’t know about, or maybe some aspect of this widget has already been written by another group in your company. Without that estimate you may have never had that conversation. The group could have had the story grooming session then gone off happily and started working only to realize later that these misunderstandings existed. What a shame that would be!
What you can do tomorrow:
Don’t stop estimating, rather reframe how you think about this tool. Start thinking of estimates as a tool that can help groups of people reduce ambiguity and gain clarity on a topic. Don’t worry so much about being victimized by a process.
I mean, sure, we could point out the process is broken. But has that ever helped anyone?
Focus on the good, and there’s a chance things might get better.
The choice is yours.
It’s about that time for people to look back on the year. While it has been a fantastic year for me, this blog isn’t about me as much as it is about you — or, at least, it is about possibilities for you. Every week or two I post an idea, a tip, a lesson, and interview, that I hope will have some value for you.
Today, I’d like to review the five most popular posts I made in 2013, just in case you missed them, and introduce the big new shakeup that is coming in January, 2014.
Getting to a conference in Europe can be intimidating, so last month I published The Hitchhiker’s Guide to Agile Testing Days. It’s a good post about getting to Germany and things to do outside the conference center.
There is another part of the conference though, something folks rarely talk about: What do you do outside regular conference hours?
At some software conferences the answer is “go to Disney” or “Explore San Francisco.” At Agile Test Days, the conference has events scheduled from 5PM to … well … late. Here’s a few things to expect, and plan for, after hours at Agile Testing Days. Continued »
Last time I introduced Cubu, a game that appeared, on its surface, to be about pattern matching, but actually works on multiple levels.
I find that more than a little bit like office politics.
Even the ‘tag’ line of Cubu – “Where Visual Illusion Leads to Confusion” has a hidden meaning. Yes, the different colored rectangles can “throw you off”, but even worse than the rings is the chance to be focusing on the rings while your opponents are playing the meta-game.
Today I’ll explain the game of office politics — and one way to play. Continued »
First there is the procrastination, the putting off until tomorrow. Next comes the freak-out that tomorrow is actually here, the mad rush to get something, the vague feeling that it was the wrong thing, which sticks around until Christmas actually come …
Yeah. It’s kind of like that.
If Christmas shopping is for you anything like it is for me, well then, allow me to introduce a little card game you’ve never heard of: Cubu, and why your friends, family, spouse, and significant other are going to like it so much. Continued »
You know the signs. The project deliverables are vague; no one knows exactly what they are supposed to be doing. The hardware might not be on-site site yet — it might not be ordered. Perhaps there won’t be any hardware at all; instead, vague promises are made that Amazon’s EC2, or some other cloud, will make the hardware needs obsolete.
Somewhere in the back, someone is sighing and nodding their head, saying “This is never gonna work.”
You want to listen to that guy, you really do. Perhaps you are that guy … but the evidence against the status quo boils down to you saying “nu uh!”
Most of us know the easy way to get a technical job — go to MIT, Carnegie Mellon, the University of California at Berkely (or failing that, the best school you can get into) and earn a bachelor’s degree in Computer Science.
While that may be the way to get into Google or Microsoft, it also means you have to be at a certain privileged position, and make the right decision, about the age of 16, 17, 18, or 19.
After that, you may have a wife, a mortgage, children.
How do you get a programming job at 30?
Travis Klein may have a way. Continued »