Been a while since I’ve felt this way, but Python brought it back out. Python programming is pretty addictive. I find myself pondering the next little Python ditty to whip up, and going through withdrawal without it. Gotta get my Python fix!
If you’re a developer who can taste a good design, a good implementation, you know what I mean.
Of course, there are plenty of things I wouldn’t write in Python.
Snooping in the QuickBooks 2013 installation directory, I find a couple boost libraries:
Not a lot of boost, but some. And they’re a few years old, but still fine.
Software-as-a-Service has its downsides, as one commenter notes:
We’re beginning to see the pitfalls of software-as-a-service in general: loss of control for for the user, increased security risks, and being entirely at the mercy of the providers’ future business strategies.
The context is Google discontinuing its RSS Reader.
A small outfit has motivation that a big one doesn’t. It matters not just to the provider, but the user. Opportunity abounds.
Here’s an outstanding video on how collaboration can not only kill creativity, but dupe our very perceptions. Steve Wozniak:
Most inventors and engineers I have met are like me: they’re shy and they live in their heads. They’re almost like artists. In fact, the very best of them are artists. And artists work best alone where they can control an invention’s design without a lot of other people designing it for marketing or some other committee. I don’t believe anything revolutionary has ever been invented by committee. If you’re that rare engineer who is an inventor and also an artist, I’m going to give you some advice that might be hard to take. That advice is: work alone. You’re going to be best able to design revolutionary products and features if you’re working on your own. Not on a committee. Not on a team.
And it gets better from here.
You’ll undoubtedly apply it to situations closest to your heart. It resonates with me and the software I write. Of course we can’t just make up our own requirements, but the final product needs to come from you.
I also hear a call to courage. Don’t be arrogant, but stand your ground. Use your best judgment. Don’t be dulled–or let your project be dulled–by the strongest personalities in the room.
They’re smaller, simpler, probably more vulnerable, and the tools to see into them not as well developed.
You Should Put Antivirus Software on Your Phone
That provocative title from Dan Shipper:
Part of me is thinking: in some ways, you were a terrible programmer
Other part is, well … it’s worked perfectly for the last 20 months and I’ve never had to touch it.
Like most things in life, the answer to what a good coder is, is somewhere in between the guy who wants to get it out fast and the guy who wants to make it beautiful.
His post-script is also a profound trueism in software:
P.S. In my defense, the find_art.js file that Scott was referencing was supposed to be a prototype. They weren’t sure if people would actually use the feature and wanted to test it. It ended up being so popular that they left it in!
From The Atlantic:
The underlying problem here is that most software is not very good. Writing good software is hard. There are thousands of opportunities to make mistakes. More importantly, it’s difficult if not impossible to anticipate all the situations that a software program will be faced with, especially when–as was the case for both UBS and Knight–it is interacting with other software programs that are not under your control. It’s difficult to test software properly if you don’t know all the use cases that it’s going to have to support.
Though there are a number of angles to this piece (and you should read it all), here’s another nugget:
This is one problem that regulation probably can’t solve directly. How can you write a rule saying that companies have to write good software?