Foreach/org

How do you reason your purchases?

For example: I love Timelyapp. I love it so much that I would like to be a shareholder. I like their approach, I like their execution. I support what they are trying to do and I believe they can, will, and maybe already are very successful at it.

I am not subscribed to Netflix. I am not subscribed to Amazon Prime, HBO, I don't buy things of iTunes, I don't subscribe to Spotify or Grooveshark or any other music service.

I buy books. I subscribed to Timely. And it's such a selfish thing.

A timely subscription costs $14. In New York that's anywhere from 2-3 coffee cups at many fine places like Joe, Brooklyn Roasting Company, myWayCup and many others. My backwater place in the world... the same money would get me about 8 cups of the same stuff.

Is 8 cups of coffee worth it for a glorified replacement for Excel?

For me, yes. Hell yes.

I am unable to fathom the pain of developing at least 4 time trackers, task managers, project management software, ... just to make it easier. Or just to implement what people want, but not necessarily what people need, only to be forgotten, discarded at the way side - for being too complex, too time consuming, too much.

I need Timely. I want timely to be better. I am willing to make something to make Timely better. I am willing to *give* something to make Timely better. It seems to be the deciding reason why I feel good giving money for the service. And that's the difference between Amazon and Timely in my case - I pay Amazon for a flawless service, and I pay Timely to improve, to survive, to flourish.

I hope it will. As for me, I'll drink a bit less coffee.

In my many years as a software developer, this is one phrase which I have heard over and over: "Don't optimize your software prematurely."

I have no idea where the phrase came from. I know that most software is shit because people don't know any better. And generalities like this encourage people to write bad software. I will try to list a few things that I think make up a good developer culture.

Invest in people, not hardware

Developers should be encouraged to think about possible bottlenecks before they happen. Generally, this is called planning, or in some extreme cases, premonition. As long as people are paying attention to detail, the problems will be obvious before they happen.

The thing which I see too often is that a lot of managers throw faster SSD's, more ram, faster and more CPU cores at the problems which shouldn't exist in the first place. This encourages a culture of programmers which think every problem is solvable by more hardware. You wouldn't believe how much running costs we have saved by correctly writing the software in the first place, and then additionally only tweaking the few bottlenecks that were found after the fact, mostly caused by feature creep.

Share your failures

If you make mistakes, learn from them. Define what you did wrong. Admit to your problems and share your failures. If anything, a developer should be comfortable admitting his failures, rather than hiding them. To quote the old adage "The first step to fixing a problem is admitting you have one." and regarding sharing your problems: "Those who cannot remember the past are condemned to repeat it."

Admitting problems shows integrity, which in turn increases trust. Nobody is perfect, it is only how you handle failure that defines you as a person. I'd take the programmer who admits his failures and works on them any day of the week, because I will trust them to say what is and what isn't going well. Sharing the problems with other developers means other people can also learn from their failures.

Specialize

Don't be the guy who knows and does the little bit of everything. While this is fine for individuals and small teams, being specialized is better than being generally good at everything. That's my theory at least.

An expert for SQL only has one problem domain the whole day. Writing SQL queries, preforming DBA tasks. His problem domain becomes his life, he knows how to set indexes and create database structures and squeeze the last bit of performance out of the SQL services.

Now imagine that SQL guy having to work with JavaScript as well. Write some JavaScript, work on some SQL, write more JavaScript. The attention to detail falls by the wayside soon enough, and time is lost in the context switching between the two problem domains.

A specialized developer will solve problems in his own problem domain by a factor faster and better than other developers. I have seen this many times over in projects over the last 10 years, small and large. Specialized programmers however will choke if they have to work on projects that require many skill sets from them. There are not many exceptions to this rule.

Ask for help

You don't need to do everything yourself. Delegate. Figure out what needs doing and what is important. Inevitably there are people around you who are better than you at something. Communicate.

This section could be called team work, but I find it important to get the message to your head that you are an individual. Your skills are your own, and other people have other skills that might be better than yours. You don't need to know and do everything, and don't be afraid to ask for help when you need it. You can search and talk about things outside your company and connect with the local developer community.

In conclusion...

Out of context managers use the phrase "don't optimize prematurely" as another way to say "write code quickly". In practice, performance goals have to be kept in mind, with a balance between design and optimization.

You will inevitably work with some bad programmers or contractors. The "shining light" at the end of this tunnel however is, that the better you are at your craft, the better people you have around you. I've seen good programmers rise out of very unconventional places.

"Cream always rises to the top"

I was loosing my shit over the last few days where I tried to track down an encoding issue in the emails being sent out for a client. The problematic client was Outlook 2010. If the email was sent to the exchange account, the contents were just fine, displaying the special UTF-8 characters. If it was sent to GMail, it was also fine in the browser. But having the account added via IMAP to Outlook 2010 displayed the email contents with garbled special characters in the client (utf-8 encoded characters displayed in a windows-1250 character set).

Somehow, to make this work, you have to send a quoted printable encoded title INCLUDING a special character (Čebela, spoštovani,...). If the title has any special characters, the whole e-mail will display correctly with this combination.

I can only assume that GMail changes the Content-type charset if the e-mail subject line doesn't need any encoding, and wrongly assumes that the content is also latin1/something. Either that, or somehow Outlook + IMAP combination tries to guess what kind of charset the mail is composed in just by looking at the imap mail list, and then again... blammo. Either way, stick a č or something into the subject line and the body will display normally.

Microsoft/Google, I don't care who does it but, please give me two days of my life back.

Thanks.

p.s. moral of the story is that I had a beer at lunch. If I had one yesterday, the problem would already have been solved. Vitamin B or whatever is in there makes you a superhuman coding machine.

If there is something every developer (not just PHP) should know, it's when to use a strict equality operator. Interestingly enough, using empty() in PHP has exact behavior as checking loose equality with `== false`.

This whole thing was inspired (and partially ripped off of) the JavaScript Equality Table. The design caught my eye, more than anything. I'm kinda wishing most if not all languages would have this kind of basic reference.

In fact, I find it to be a very useful way to document operators. I'm always kicking myself in the head when I go read some lua code which doesn't use "!=", but uses "~=", and then there's other software where the '~' character doesn't mean negation but regular expression (perl =~, nginx regex locations). It's the little things.