Load info is a neat website that lets you generate your own loading icon.
The first page has a hypnotising array of load-icons to choose. Click on one and it'll bring up a box that lets you choose the size and colours you want and it'll generate you a customised animated gif you can use.
Ben Orenstein has written an interesting article: How much should global variables cost?.
It's basically a price-list for different kinds of technical debt, and you can use it to calculate the "cost" that each of your commits adds to your codebase. By actually putting a dollar amount on each "violation" - you can get a good, visceral feel for what you're doing.
As he points out - you can still choose whether or not to keep something (sometimes you really do need to do something that would otherwise be considered a no-no), as long as you can "afford" it.
I think it's an interesting way of looking at the problem. I'd like to see you regaining points for fixing/refactoring similar code-violations out of the project too :)
An old guest blogpost on RailsInside caught my interest, called The perils of opinionated software like Rails. It's never a good idea to get too fanatical about one's choice of framework - so I definitely recommend having a read.
He raises some good points, including the should-be-obvious "the opposite of bad software is not necessarily good software". The specific ideas he raises are surrounding Rails' poor re-implementation of database security-checks - something that old, enterprisey-style applications leave up to the actual database, because that's been a solved problem for years. Recent versions of Rails are better at this, but I think his message is still important. We should always keep in mind that old enterprisey software may still have some good stuff that we maybe aren't using more through fear of looking enterprisey ourselves, rather than because it's actually not a good idea.
Finding good "help" is always tough. When your help is located thousands of miles away in a country where english is a second language... that can be even tougher. How exactly do you filter out the dross and find the diamonds?
C42 have just put up a really interesting tutorial on how to identify offshore ruby on rails vendors that don't suck. I've never outsourced myself, but this looks like it would be a good starting point.
Anneke Jong has posted an interesting article called why we need to rethink women in tech, which points out the real reason for the seeming disparity in numbers of "women in tech" comes about due to the definition of "in tech" being used.
She explains that while several recent articles are applauding the increase of "women in tech" - these numbers are gathered from women who are, in essence, working in tech-adjacent roles (eg marketing and PR for IT firms, or tech-bloggers such as herself), rather than actually having coding skills - which would be the definition of "technical" for those working in the industry.
As a coder-girl myself, I can see her point. There has indeed been a great uptake of "women in tech"... but the increase of actually technically-competent women is much slower.
While the figures quoted in media seem good at first glance - they aren't telling the full story of the gender imbalance. Anneke makes a great comparison with the music industry: "Imagine your disappointment if only a third of the 'Top Women in Music' were musicians."
This is not to say there has been no progress over the last twenty years. When I began my Comp Sci degree, I was one of only seven women in a class of 220, which was no uncommon at the time - whereas now the proportion is closer to 1 in 10... but that is still a far cry from 50%
The article, of course, offers no solutions - because generating interest for computing (or maths, for that matter) in women is still one of the Hard Problems facing education... but it's a good discussion of the problem, and worth a read.
An interesting point here that is quite true. Effort isn't enough... however - is it really possible to compare groups of IT guys against "industry average"? What data do we have on "industry average"?
Have we gathered reliable data on any of these? How would be go about collecting it and is it even really possible to do that reliably?
I guess it's possible if you're doing work that's already been done (eg building a better mousetrap)... maybe if you're churning out cookie-cutter brochure-ware websites perhaps? Or Yet Another Spreadsheet App?
Even so - I'd be curious how you'd determine the productivity of other groups in your industry - what is it exactly that we're averaging? Time to complete features? Code quality? Lines Of Code? :|
Even if we decide on a metric, asking people in your own company about their past experiences will only give you a few datapoints - possibly distorted by 20/20 hindsight (or whether you want to come off looking better than reality might show up). I don't know of any reliable info out there apart from this kind of self-gathered stuff.
How do we go about gathering data across companies and how do we trust that data? It'd still be self-reported and therefore open to various forms of bias ("Yeah, my *old* team used to be awesome! nothing like this group of idiots!"), differing levels of slave-driving ("Yes, *my* team got it done in a week... just ignore the shackles on their legs!"), differing levels of quality ("we got it done over a weekend! security? testing? what's that?") and downright manipulation ("yeah, we're Team Awesome and can code up a custom-built website in only 24hours!!!!")
Not that it wouldn't be worth giving it a go.. but of course you still fall back on the problem of metrics. What metrics reliably indicate productivity (especially when we need to hold code quality constant)?
"Features" produced per week perhaps? but what is a "feature"? how big is it? how do we compare across companies and even across industries? It's a tough call - made even harder when you add the "quality" constraint. Is a cavalier team churning out unplanned, untested code full of security holes *more* productive than a careful one that designs something elegant and simple, robust and well-tested?
Measuring quality is always a tough nut to crack.
I've seen people try for "customer satisfaction" - but in our industry, it also pays to ask "which customer?" - the one paying the bill or the one that is forced to actually use the product? Another example of Who is the real user here?
So... are there any resources out there? and what's people's experiences of their quality?
Who should learn to program presents a brief look at the reasons why everyone should learn to program, and also a very good reason why not. Worth a look.
A fairly standard question on quora: Why are software development task estimations regularly off by a factor of 2-3? has sparked some discussion.
The best answer given was an extremely entertaining hiking analogy (it's the top-voted answer - go see), explaining the software development process in terms of the fractal-nature of a coastline, with unexpected delays along the way.
I think it's a great analogy as it goes and would be extremely helpful in getting the idea of unexpected scope-creep across to a complete IT-newbie.
The answer then spawned a plethora of comments and even a counter-post that is also really interesting: Why Software Development Estimations Are Regularly Off, which explains that the hiking analogy is way off, and that software estimation is more like inventing.
I agree... though I still see great value in the hiking analogy for explaining "what goes wrong" on the kind of project that encounters the problems described.
The counter-post has itself sparked a discussion on Y-combinator which goes into a lot more detail about estimation issues in general.
It's all provided me with an entertaining read on an otherwise well-picked-over subject.
OMG how much do I love this oath!!!
I might put it in my standard contract going forward :)
The hungry programmer compares healthy eating to healthy code-practices, discussing the code-quality equivalent of the "healthy eating continuum". In brief:
If you take the McDonald's approach and ship shit then you satisfy that need in the short-term. But you'll feel the effects in the long-term. Your code will be harder to maintain and need more attention later. It won't have a long and healthy life.
I know there have been several times when we just *had* to ship *something*... no matter the guilt I felt at the poor quality that was going out the door. I much prefer to spend some time *now* and work at the better-quality result - even if it means "going hungry" for just that little bit longer. Still, I also understand that a business has to ship to remain a viable business... It's one of those universal dilemmas.
What experiences have you had? Any spectacularly difficult trade-offs you had to make?
It's fairly old, but this is still a good basic reference to SEO and link-building
Just be aware that IPL2 is no longer accepting link submissions. You have to register as an editor for joeant to be able to submit to them (which is free, and you don't have to submit any other links, though it helps).
This one also has some good ideas:
How to build links fast
...and some hilariously dumb ones at the end (including "sue google" and the RIAA technique). :)
Anybody have any more recent good tutorials on link-building?
I've also read The 4-hour work week and dreamed about relaxing on a tropical island while the money pours in... but the truth is that it's actually a lot of hard work to get to that stage.
The biggest myth surrounding passive income is that it's a "set and forget" strategy. The truth is that it does actually take a lot of work, up-front to get that ball rolling.
Nacie's article weighs up whether passive income is all it's cracked up to be.
Too many people read "four hours" and think that passive income is the *easy* path to success... far from it. You'll most likely get far more up-front cash coming in via a traditional entrepreneurial route. Sure, some superstars will hit it lucky up-front and be an immediate smash, but for most of us working-joes, "passive" is all about building over the long-term; and keep in mind that it will take a long-term effort to get a full-on passive cashflow. In the meantime, you'll probably have to start with a more traditional business or job until your passive streams grow enough to be sustaining.
Have a look at what Steve says if you want to know the real consequences of trying to take the easy route when launching your own business.
Now, don't take all this to mean that "4 hours" is all a lie. As far as I'm aware, it never states that you can make money with no effort at all - or that you'll even make more money that way than the traditional routes... It's quite clear that it's handbook about really useful ways of simplifying and delegating as many parts of your business as possible. The main point being that you are building a "maintenance free" business, rather than a "totally effortless" business.
It's definitely true that people *can* make passive income work this way. Just keep in mind that it won't happen overnight and it's won't happen with absolutely no effort at all.
Anybody here have experiences with putting into practice what they found in "four hours" or any other version of a passive income stream? How did it work out for you?
As a telecommuter, I well know the struggle with self-discipline. It's very hard to keep away from all the regular home-distractions and actually get down to work. But it's a necessary part of every day life.
This article on training self-discipline has some good tips on how the author has been working towards better self-discipline, and also some good general discussion on the benefits.
I especially agree with his point that you need much more discipline if you have large amounts of freedom. I remember it being much easier to get down to work when I had to actually get up and go into the office at a set time each day.
Anybody else here telecommute? Do you do anything to wok on your own self-discipline?
I've just come across: Computer Stupidities. Its a lot of fun. I think my favourite so far is:
When I was studying programming, one of my classmates was having serious troubles with his program. When he asked me for help, I leaned over his screen and saw all of his code in comments. The reason: "Well, it compiles much faster that way."
Much like Daily WTF... though most of the CS stories are very early era
Corporations and governments spend staggering amounts of money on forecasting, and one might think they would be keenly interested in determining the worth of their purchases and ensuring they are the very best available. But most aren’t. They spend little or nothing analyzing the accuracy of forecasts and not much more on research to develop and compare forecasting methods. Some even persist in using forecasts that are manifestly unreliable. … This widespread lack of curiosity … is a phenomenon worthy of investigation.
An eye-opening article by Robin Hanson, called Who Cares About Forecast Accuracy?, describes how and why corporations spend heaps of money on making predictions... but almost none on testing whether those predictions actually worked out.
The article discusses the fact that actually recording the accuracy of pie-in-the-sky forecasts means that it's much harder to hide a poor track-record for leadership. That a lot of forecasting is more about signaling affiliation to the company ("yeah, we're doing great, I predict we'll be done by tomorrow!") than actual accuracy. Quite possibly just another effect of bosses preferring overconfidence to accuracy.
From my own experience - I find that many "leaders" don't want you to say that the project might be in trouble... and the article discusses how this can happen because the middle-managers don't want somebody to go on record as having questioned their vision... because it'll reflect badly on them down the line should something go wrong. It's much harder to sweep losses under the carpet if nobody officially takes notice of how often it happens.
I think there's also another reason, not mentioned in the article. That being the long-term vs short-term payoffs. The strategic echelons of an organisation need your predictions so that they can make their own overall predictions of how long a plan will take to implement. But they don't want to bother with the long-term cost of implementing a full system with all the process-change and downtime that it will take. I've personally found it extremely difficult to "sell" both management and fellow-programmers on changing to to a methodology which will allow for recording and feedback of prediction accuracy. These are methodologies that aren't particularly heavy or difficult to implement (compared, say, with six-sigma), but which provide a quick and easy way to get better at providing an accurate estimate of your times.
The problem seems to be, that it takes more time and effort to implement, and people don't want to do the "work". They want to make their guesses *and* make t more accurate... but not to have it impact the "bottom ilne" in any way. This is a bit like saying "we'd like to buy faster computers, but won't give you any budget for their increased cost". You somehow have to just improve anyway.
What normally ends up happening is that you don't properly implement any system of accuracy, so you end up simply guessing and just hope for the best. Actually spending the effort to make those guesses meaningful is too much like hard work, and nobody wants to add to their workload. This is understandable... but not exactly helpful (or realistic). Instead of improving over time, we continually wallow in a world of wild guesstimates and "fudge-factors" that never seem to quite cover the extra time it always seems to take.
To get back to the article, Hanson suggests that we use a betting-system to literally "put your money where your mouth is"... the intention being that if you personally stand to win/lose by your prediction, then it would be in your best interest to start being more accurate.
I think I'd balk at my own actual money, but I'm sure some kind of system could be set up for "points" where you "win" various rewards (eg an extra day off, or even just the ability to work on "the fun project") if you do especially well.
Has anybody had any experience with estimates and measuring their accuracy? Either from the trenches or the strategic side of things?
I've found a fun new site. Project Euler is a huge set of math+programming puzzles of increasing difficulty, starting out pretty easy (solved by tens of thousands of participants) and going up to puzzles that haven't been solved yet.
They're quite fun. Each one touches some aspect of mathematics, and requires some programming smarts to get it working. But don't worry if you're not cluey on maths. They start out fairly simple, and you can google for information about the math behind the puzzles if you need more.
Each puzzle has a specific, numerical answer. You submit the answer to prove you've solved the puzzle, and the site keeps track of how many you've done. It also gives you access to a forum for each puzzle - where others share their code or insights into how to make the program more efficient. Most puzzles also come with a short pdf to explain the maths behind it - generally showing you how to analyse the problem or prove the formulae behind the most efficient algorithm.
Each puzzle has been constructed so that the correct program/solution is expected to run in under a minute... and for many of the puzzles - that means you'll have to rethink how your program works to get in under that time.
Anyway, I think it's an interesting challenge to play with. Here's my score so far:
Angry Birds is one of the most successful games out there right now - consuming millions of hours worldwide every day. What have they got right? This article tears down the user experience and explains Why Angry Birds is so successful and popular. It's a thorough and thought-provoking look into the sorts of things that make up a truly engaging user experience.
In How to understand everything and why, Eric Drexler (author of Engines of Creation), explains the importance of a broad education simply:
"It’s important... because it makes creative work more productive and makes costly blunders less likely... "To avoid blunders and absurdities, to recognize cross-disciplinary opportunities, and to make sense of new ideas, requires knowledge of at least the outlines of every field that might be relevant to the topics of interest."
he then follows with a brief discussion of how to go about learning everything - a method that seems straightforward, and even fun. Worth a read.
Seth Godin's blog is packed full of great insights, but I thought I'd outline a recent one.
Assuming Goodwill is about the decision to trust, because trust pays.
It's one of those common-sense things that we often forget, that people will live up to your expectations. Expect the worst and that's what you'll get, but expect great things and you'll get the best. Seth talks about trust as it relates to, say, a restaurant trusting you to pay *after* you've eaten your meal... or Tiffany's trusting you to try on their expensive jewels... but obviously this has application to the full breadth of life.
For example, an employer trusting their employees to be productive and loyal builds an environment that is more conducive to productivity and loyalty, than one who micromanages productivity, or constructs labyrinthine rules about allowed corporate protocol.
Yep, sometimes your trust will be abused... life is like that. But sometimes you have to risk a little, to gain a lot.
