As a writer, were there any benefits to you to grant that permission? Or was it more along the lines of there being no downside and it's nice to be asked?
You tell your boss something along the lines of "I've never worked with Perl before, and I don't think I'm going to be able to complete the project with the time we've budgeted, since it can take some time getting up to speed with a new language." Then you present options iike using a language you're comfortable in, or lengthening the time that's available for the project.
Often part of a technical job, particularly a technical job with any interesting work or responsibility, is educating your boss about the true costs associated with a decision so that they can make good decisions. If they want you to do it in Perl, that's fine, they're paying for the time and you've informed them why it will cost more than they thought. It's a good idea to follow up with an email restating this so that there's a written record you can point to later when the project falls through.
Honestly, I had expected that you'd refused a project that was unethical or illegal, not that you'd just decided you weren't interested in the stack they wanted you to use. If you told me that story during an interview, I certainly wouldn't hire you. It shows a level of inflexibility as a developer that makes me seriously question if the reason you refused the work is because you're not capable of picking up another language.
Five years ago I was at HOPE Number Six and Michael Hart was the Saturday keynote speaker, giving a talk on his work at Project Gutenberg. I didn't know very much about it, but I recognized the name. There were Project Gutenberg discs floating around the conference so I snagged one and had a look.
I don't really remember anything specific from the talk, but I remember it was inspiring. It was called "Using eBooks to Break Down the Bars of Ignorance and Illiteracy". There's audio of the talk online, and I think I need to hear it again.
The next day was the last day of the conference, and as was usual Jello Biafra was the getting far less attention than the other keynote speakers. They'd closed off the back part of the main hall, a hall which had been filled to capacity and then some for Michael, and some of us were tossing around beach balls. I pounded one particularly hard and hit some guy in the back of the head with it. When he turned around I recognized Michael. I don't think he was too happy with me in that moment.
With the eloquence that only a twenty year old can muster, I stuck my hand out and said "I love your work. It's fucking absurd." That's about the highest compliment I can give a person, and I'm glad to see that Shaw quote in the obituary. It says what I was awkwardly trying to express.
The tension drained out of the situation, and he shook my hand before turning back to his companion and returning to his conversation. I went back to playing with beach balls.
I admire what Michael built, and I admire how he did it. Project Gutenberg was slow but steady, and will continue past his death. I can only aspire to leaving that kind of a legacy.
Goodbye Michael. I loved your work. It's fucking absurd.
I think there are a lot of founders who don't code on their company's product anymore (though it's apparently not a pure factor of size – Gates and Zuckerberg are known for actually writing code many years in), but it'd be weird if they didn't write code at all. It would imply that writing code is never the most efficient way to accomplish a task that they want solved. Even with infinite resources at your beck and call, it's often faster to write a quick script than to explain to someone else what that script should do (and to continue to do so through whatever iterations seem appropriate).
I'm tempted to say that those who don't continue to hack were never really hackers in the first place. For a hacker, writing code is just one of the normal ways to interact with a computer.
I think there's an even more subtle implication that pg is too busy (and should be) to code, yet he still CHOOSES to continue to code. Obviously it would be really easy to find someone to do the coding work - whether keeping up with HN or the creating investor/startup interface - but his choice to continue coding is a statement he and the article are making.
There is a bias with many management and business people, they think coding is low level cruft done by expendable people and once you become a manager or start doing business you start doing the real work and don't have to deal with this lesser things.
Sadly I've seen this a lot. Even more sad is that I know programmers that have become managers, no longer write code, and loathe the days they were simply coders. It pains me.
The other extreme is people who can never see technical entrepreneurs as anything other than coders.
A week ago I was having coffee with the new VP of Marketing for a company I consult to. Despite my background: MBA 8 years ago, founder of web startup that was acquired, several years in product management prior to that, the veep asked me why I didn't wan to be a programmer. What?
I still code, but I find it annoying when people perceive me as coder first, as though that invalidates my business credentials.
Maybe I'm putting out the wrong vibe, but I'd like to chalk this up to them being threatened by the idea that someone with a skillset they will never have can do all the same stuff they can.
When your business outgrow "garage" level it's simply starts to generate MORE and INTERESTING questions than what you could work out yourself, so you just make the decision(give to others) and enjoy the feedback from the results..
It's not that you don't like to code, you just enjoy to be connected and entertained by more stuff.
Of course a great counter example is John Carmack - in there I think he is far more interested in the exact technical details than your average entrepreneur - btw he was never an entrepreneur, he is a "pure" engineer with obsession to optimize(and many other sides of course).
I took an awful lot of graduate level courses as an undergrad. Most of the time there was some sort of additional vetting where the prof had to sign off on your involvement in advance.
You don't have to get very far in the undergrad before they'll start letting you take the interesting stuff, especially if it looks like you know what you're doing.
Are you planning on maintaining these? In my city the route timings change depending on school schedules and time of year, so the transit schedule's that are posted at stops have to be swapped out three or four times a year.
That's superb then. My big concern for any project like this is that maintenance and upkeep costs end up outstripping the initial layout by a considerable amount.
3.2 for my app that needs interface builder plug-ins, and 4.whatever-the-latest-is for my other stuff. My general rule with all things Apple is to keep at the forefront of what's available, unless you have a very good reason not to. Apple isn't sentimental about dropping support for older products.
If it has potential to cause customer confusion, it might be a trademark violation. A company is required to defend their trademarked terms, otherwise they may become generic terms.
(Standard I Am Not a Lawyer disclaimer. Go talk to a real one if you're worried.)
Asking if design makes a difference is kind of a silly question. We know it makes a difference. Using A/B testing, or even just by changing one element at a time, we can measure improvements in things like conversion ratios or download rates.
Of course, to measure if each part of your design is effective, you have to change it in isolation. I wouldn't surprised if there are elements of the new Wordpress site that decrease conversion, as well as some which are increasing it. If the design had been iterated on, instead of just rolling out the new design, we might know which elements should have been changed to create better results.
A/B tests show their limits when it comes to design. You can't A/B test a brand or a logo, or even a background or a font. And you can't test elements of a new design in isolation, that doesn't make any sense. Elements of a design have to work together as a whole.
Everything you've listed except for a "brand" (and the usage here seems pretty ill-defined) is very A/B testable. I'm not really sure how to refute that, but the idea that they aren't is ridiculous. Would that be effective and produce good results? Maybe not - that's a great discussion to have, but whether or not it's possible isn't.
Similarly, you're right - elements of a design do not exist in isolation. However, any design will have a series of choices that resulted in its various elements. Some choices are small/minor enough that there exist other elements that also work together with the whole, and so A/B testing them isn't some insult to the idea of design, but an at least plausible decision-making tactic.
Well ok, you could A/B test replacing Arial by Helvetica, but it would be pretty meaningless and probably not make any difference.
That doesn't mean that there is no difference. Maybe on a subconscious level, people would start to perceive your site and relate to your brand differently.
And maybe changing the font, and then the background separately would not make a difference, but changing both at the same time would make an impact. All those things are A/B testable in theory, but I don't think it would be very effective.
If you think the background and the font together are going to make a change, then by all means, conduct a test and see if whichever metric you're working with goes up. I'm in favour of isolating changes as much as possible, but if you believe that two elements of your design work only in concert with each other, then they should be modified accordingly. These aren't random permutations you test, they're new tweaks to a design that you suspect might help.
Sure, changing the font may be meaningless, but at least with a test, you KNOW it's meaningless. I try to let experience and taste guide my changes, but without checking that the change is effective you're just guessing.
Design exists to further a goal. Sometimes the goal is brand related, which I'll admit is just about impossible to measure, and sometimes it's seeing if you can reduce the frequency of support requests. One of these is obviously a better candidate for A/B testing.
