Scott Westerman: If you will it, it is no dream:
I tell the people I serve to start from the premise that all things are possible. Work backwards from there. Charles Kettering’s wise counsel that “Our imagination is the only limit to what we can hope to have in the future,” was never more true.
Here’s hoping that more of my geek friends can develop that outlook.
And a little Flash to boot 🙂
Flash sounds like a perfect tool to teach programming. Others I’ve been reading about:
Scratch (scratch is built on Squeak Smalltalk – there are other educational environments/tools built with it as well)
My roots: LOGO and Commodore BASIC.
Interesting related article at O’Reilly: Why Johnny Can’t Program.
From Locus Magazine: Cory Doctorow: Writing in the Age of Distraction:
Read the whole piece for the thoughts behind these items of advice.
There are equivalents for programming that come to mind. I wonder, am I sliding back into Emacs a task at a time because I want to kill my word-processor (my IDE – Eclipse?)? Is that why Netbeans is starting to appeal to me (seemingly less work configuring (playing?!) with IDE settings and concentrating on the task at hand)?
On loving what you do and practice
I love what I do. That doesn’t mean I don’t recognize it as hard work – but I do believe I am one of the few lucky ones who has found a career that challenges, excites, and pays the bills. I repeat however – it is hard work. There are no free rides in life. You need to work at what you do in order to be a success at it.
Coding Horror: Programming: Love It or Leave It and the thread at Joel on Software that inspired the post – “Thinking of leaving the industry”.
Tim O’Reilly: Hard Work and Practice in Programming – an email thread discussion about programming, learning, and practice. via rc3.org.
On constructive criticism and feedback
ThousandtyOne!: Leadership, Constructive Criticism And Not Playing The Blame Game:
In the world of software development most managers are taught the blame game, right when they are young and budding management students, business analysts or programmers taking their first fumbling steps at managing a team. For most managers, blaming the process, an individual’s incompetence or the whole team’s incompetence is an easy excuse for all failures; including theirs. I’ve hardly ever seen managers personally attached to team members, spending genuine effort in trying to help them find their core competencies and coming forward to blatantly own up failures and take responsibility when things don’t work out.
I’ve hardly ever seen managers lending constructive one on one direct verbal criticism followed by genuine help. I’m not talking about a generalized you-need-to-get-better-at-coding-email followed by be-careful-next-time-email followed by I-am-going-home-but-check-in-the-code-and-email-me-the-status-as-soon-as-possible kind of criticism here.
I’m talking about the blatant and precise your-use-of-object-orientation-in-the-administration-module-sucks said with empathy, followed by a joke, followed by lets-go-out-for-a-cup-of-coffee, followed by lets-stay-late-and-refractor-together kind of constructive criticism. Or for that matter, let’s-meet-during-the-weekend-and-fix-this kind of constructive criticism; and that dear reader, irrespective of what they tell you, is not a waste of your time; it’s what you were hired to do; especially If you were hired to lead a team. If you weren’t specifically hired to do that, I suggest that you do it anyways.
If you work with a team, don’t criticize ruthlessly; if you lead a team don’t play the blame game; and remember, it doesn’t matter what they teach you in management schools or tell you at your workplace, if your project isn’t cruising along successfully, it’s always your fault.
If you must criticize, do so constructively, followed by empathy, followed by genuine help. I can’t teach you how to do that. What I can do, however, dear reader, is end this post abruptly and rather dramatically, leaving you with words of wisdom worth pondering on, from one of my all time favorite movies. Here’s Wishing you, good leadership, healthy teams and a good life.
Jonathan Lange: Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews:
Code reviews provide an amazing opportunity to grow as a programmer and to improve the software we make. There are many choices that a project can make about how reviews are done and what they can achieve. By thinking carefully about how technologies and processes affect the basic human interactions involved in code review, open source projects can avoid traps that scare off newcomers or wear down longstanding contributors and instead focus on building the best software possible.
Some unrelated additional links
devChix: Beautiful Python: The programming language that taught me how to love again
Software for Civic Life: An Interview with Mike Mathieu of Frontseat.org
I would read Charle Cave’s terrific tutorials regarding org-mode and remember.el in the order I’ve linked below, but it isn’t required.
Aaron Held, coworker at CIM, “A House With No Front Door Keeps you off the streets”:
Scrum and Agile are desinged to solve this by making it a team effort. So in Scrum it is not the “developers” that build this Dr Seuss house, but the team. I think this is why many people fear Scrum. There is no “justifiable failure”.
CIO.com: When Agile Projects Go Bad:
Agile development also depends upon the engagement of the sponsors or customers in the process. That’s a difficult transition for some, according to Cockburn. “It looked like for a while that we were pushing all the power down to the programmers, but in fact we were evening out the power and responsibilities. Everyone gets to feel awkward about that.” In some organizations, he says, programmers ignored their bosses and built whatever they wanted.
At the other extreme, programmers expected the bosses or managers or sponsors to tell them accurately what the priorities were–not something the managers were used to. “So you get a breakdown on both sides,” says Cockburn. “The sponsors aren’t used to being asked to show up and care about the project, even [about] the requirements. … They say ‘No, that’s what we hired you to do.'” The programmers respond, ‘We don’t know; we need you to help us figure it out,'” he adds. And the sponsors say, ‘We don’t have time. Work it out yourselves.'”
Scrum – when practiced as intended, makes it hard to for CYA measures in development, planning, or management. Aaron has a point. That’s scary to some I would think.
Steve Yegge talks about Google’s development (circa 2006) process – a process that is focused on being agile – and riffs on just how bad “Bad Agile” can be: Good Agile, Bad Agile:
Bad Agile hurts teams in several ways.
First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It’s a nicely idealistic view of the world.
In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don’t feel like focusing on coding. Some days you’re just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it’s likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks.
Not to mention your personal clock: the events happening outside your work life that occasionally demand your attention during work hours.
None of that matters in Bad Agile. If you’re feeling up the day after a big deliverable, you’re not going to code like crazy; you’re going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.
There’s also your extracurricular clock: the set of things you want to accomplish in addition to your main project: often important cleanups or other things that will ultimately improve your whole team’s productivity. Bad Agile is exceptionally bad at handling this, and usually winds up reserving large blocks of time after big milestones for everyone to catch up on their side-project time, whether they’re feeling creative or not. Bad Agile folks keep their eye on the goal, which hurts innovation. Sure, they’ll reserve time for everyone to clean up their own code base, but they’re not going to be so altruistic as to help anyone else in the company. How can you, when you’re effectively operating in a permanent day-for-day slip?
Bad Agile seems for some reason to be embraced by early risers. I think there’s some mystical relationship between the personality traits of “wakes up before dawn”, “likes static typing but not type inference”, “is organized to the point of being anal”, “likes team meetings”, and “likes Bad Agile”. I’m not quite sure what it is, but I see it a lot.
Read the whole thing.
codeartisan: Jon Moore: Cracking down on technical debt:
Generally, as the folks with the technical ability to recognize it, it is the development team’s responsibility to try to avoid accruing technical debt while producing product. Failing that, it is their responsibility to recognize/document existing debt and to advocate for its removal. However, note that there are often symptoms of technical debt, such as those I’ve listed above for architectural debt, that can be recognized by non-technical folks too.
On the flip side, business folks / product owners need to be able to trade off short term wins that accrue technical debt vs. taking longer to produce a product with less debt. Communication with the tech team is of vital importance here; undoubtedly there will be times when a short-term win will be important (especially with a first-to-market situation), but it needs to be accompanied by a plan to eliminate the accrued debt. i.e. Treat your technical debt like credit card debt that should be paid down ASAP, and not as a long-term mortgage.
The interest on your technical debt is probably not tax-deductible.
Very much related to my earlier post about Agile gone wrong.
Oh boy, does this sound familiar.
James Shore, consultant, lays down just how bad it gets when you ‘go Agile’ and don’t do so correctly: The Decline and Fall of Agile:
Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call–or one of my colleagues does. “Changes take too long and cost too much!” I hear. “Teach us about test-driven development, or pairing, or acceptance testing!” By that time, fixing the real problems requires paying back a lot of technical debt, and could take years.
What frustrates me the most is that this situation is entirely avoidable.
…There are a lot of teams right now failing with Agile. These teams are working in short cycles. The increased planning frequency has given them more control over their work and they’re discovering and fixing some problems. They feel good, and they really are seeing more success than they were before.
But they aren’t working in shared workspaces or emphasizing high-bandwidth communication. They’re don’t have on-site customers or work in cross-functional teams. They don’t even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don’t use good engineering practices.
These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff–the stuff that’s really Agile–they’re setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won’t last.