keithba

+1. I was taught this as a young lad at Intel by a graybeard who'd been developing since the 60s. It made a lot of sense then, and it makes a lot of sense now.

My favorite way to rent a car when I fly somewhere. The overall experience (mobile first in a way that makes sense and isn't just trendy) is fantastic.

They key here is to still state your salary requirements _or_ get the potential employer's range for this position.

I've been on both sides of this when both sides interview blind, and it's disappointing far too often.

Miguel de Icaza is on the board and not an MSFT employee.

"So Rob Pike is basically saying that the developers at Google aren’t very good so they’ve developed a dumbed down language so they can get things done."

I read the Pike quote very differently. When Pike says: "The key point here is our programmers are Googlers, they’re not researchers." I thought he meant programmers today use google to assist them in programming.

Milton Friedman created a reasonable argument for conservatives that this program is in-line with conservative economic principles.

http://www.nytimes.com/2006/11/23/business/23scene.html?_r=0

I've been using this for a week or so now. I wish I could figure out how to get colorized output in my SublimeREPL, but other than that, I can't say how much better this makes my clojure dev time.

I love this idea. If you can easily delete the code, you can easily refactor!

I wrote something recently on how to create small tasks for estimating (http://keithba.net/estimate-like-a-boss), which includes an example design doc and spreadsheet of the breakdown. You may find that example useful.

Generally speaking, finding a way to communicate this will depend on the engineer. Someone very junior may require much more detail both in the technical design and the feature itself. Someone more senior needs less of that.

This is very insightful.

WCF and WS-* tried very hard to handle both RPC and more asynchronous scenarios, but the tooling continued to be heavily RPC based.

I think the momentum is not on SOAP's side. But you are correct that it isn't going away, at least for legacy.

I'm writing something up on what was done right with SOAP and WS-*. (Arguably the code generation was useful for quite a few scenarios.)

I think we'll see more and more schema related projects for JSON-based API (like swagger). It will be interesting if they can compose in a way that keeps the complexity down, as opposed to what happened with SOAP.

Random nit for author: at the end in your list you are missing the actual link.

>> get a productivity tracking tool [link]

I thought it was worth the read. It's short and quick. I don't agree with everything, but it's compelling and entertaining, and thought provoking.

I also read Blake Master's blog entries back when he first wrote them, and found the book a better superset.

Thanks for the rec on Synthesis of Form!

Just completed: Zero to One.

Always reading: Christopher Alexander's The Nature of Order: The Phenomenon of Life.

The Goal is one my favorite books to recommend to anyone joining a startup, but also for product management types. I first read it around the same time I read The Lean Startup, and I found the two to be very complementary.

I agree that securing the services is important.

I don't think bidirectional TLS is enough in many cases. Defense in depth is required. You need to ensure that when services access other services, they aren't granted wide open privileges because you (hopefully, still) own them.

I would add a reasonable authentication and authorization model to this list of prereqs.

I remember being impressed with Jeff way back in those days when we all thought SOAP was a good idea. His progress at AWS has great to watch. Congrats!

An unfortunate and misguided sentiment, especially considering how technological change has literally improved and changed the world. The current top story on HN (http://www.newyorker.com/reporting/2014/07/21/140721fa_fact_...) being but one minor example.

Enterprise Integration Patterns:

http://www.amazon.com/Enterprise-Integration-Patterns-Design...

http://www.eaipatterns.com/

Covers stuff like: RPC, messages, channels, etc.

http://www.socialsecurity.gov/OACT/babynames/limits.html has links.

Neat! How did you build this? What's the stack?

Most anything by Charles Stross, especially the Laundry series (Atrocity Archives, Jennifer Morgue, etc)

>> you should try to work on what you really care about

So Good They Can't Ignore You[1] calls this the Passion Hypothesis[2], and argues (very well) that this is the wrong way to think about finding a career.

Instead, create a craftsman-like mentality and work ethic, and then use deliberate practice to get very, very good skills. With great skills, you will enjoy your work much more.

I believe this advice aligns with the rest of the blog entry very well. Creating value (and doing it well) requires an advanced skill set.

[1] http://www.amazon.com/Good-They-Cant-Ignore-You/dp/145550912...

[2] This is an arguable point, since caring about something could be different than being passionate about it.

You can use ffmpeg for this. For instance, to output one frame per second: ffmpeg -i foo.avi -r 1 -s WxH -f image2 foo-%03d.jpeg

See http://ffmpeg.org/ffmpeg.html#Video-and-Audio-file-format-co... for more examples.

Email me at {my_username} @ gmail.com. I couldn't find your email in your profile.

Back in 2007, I co-founded a startup to do something similar to this. Check out "System 7" @ http://www.kylecherry.com/ for what it looked like (I can't find examples of the software.)

We didn't succeed for non-technical reasons & died before getting to market. But here's my advice:

- go with Linux or BSD, not Windows (maybe WINE or something similar if you must run Office) - prototyping and fabrication is non-trivial - we worked with iSuppli and it was worth every penny

Absolutely agree here. I've ran into some issues occasionally with IntelliJ when reading an Eclipse tutorial and translating Eclipse concepts into IntelliJ concepts (especially around libraries and unit testing), but otherwise, I find IntelliJ much better and would have preferred I had started there.

I'm missing something - hours since the start of the year: 2671. Hours of uptime: 2641.

That lead to a downtime calc of 98.88 or so.

*edited for language clarity. Gah! Original sentence above implied that downtime was 2641.

I stand corrected - my memory was saying something between 4 and 5, but looking it up: the post-WWII avg is 5.7.