HN user

Su-Shee

149 karma
Posts0
Comments31
View on HN
No posts found.

Start with the "classics" like "mystical man month" (Brooks) for example, then get many of the books by Tom de Marco and possibly read Richard Gabriel's "Patterns of Software". The book about the "Chandler" project (forgot it's title) is also a particular good read. Those two in particular are interesting reads about why things fail.

Go on to reading the Toyota management style in itself, there's a couple of books about it, that's what many IT techiques are getting their ideas from.

It's mostly about finding your values so to speak and pinpoint what you really think makes up a good software development company - maybe your focus will be on organization, maybe on other things, so get an overview first.

These two articles are hopefully also an interesting nudge to think about many things:

http://www.computerworld.com/s/article/9137708/Opinion_The_u...

http://alistair.cockburn.us/Characterizing+people+as+non-lin...

O'Reilly has a very interesting book with analysis which practices actually work and why/how - sadly I also forget the title. There's for example a chapter about when and why pair programming works and when and why not.

Also, just watch carefully and learn to notice "good organization" - happens in surprising corners and niches and try to see WHY it's good.

PC specs: anything which can run ssh and is at hand when I need it

OS: Any Unix/Linux will do

Source/Version Control: Whatever is used where I have to do some work

Editors: vi(m), no plugins

At the end of the day, I really only need some ssh, screen, a halfway decent shell, any versioning and a vi.

Also: Pen and paper to take notes and ANY simple GUI to run a browser is appreciated.

If I can have it, I'll take it all in UTF-8, please. :)

Haha, I call them "Cassandra" usally. :)

I like working with them and having at least one on the team, because they're a great addition to the "naive optimist" or the "carefree hacker-fixer" who always see the solution around the corner - in a couple of minutes of course. ;)

And: There's a lot of tech scenarios where being overly careful and actually seeing the impending technical doom in every corner is an advantage.

Similar to the pedantry you get by the human robot, Cassandras have their place - and good management and coworkers know exactly where and how to take them.

For those interested in the science/medical side of things:

* "Zen and the Brain" (written by a meditation practising neurologist)

* "The Buddha Brain" (about the neurological/physiological background of a couple of buddhist principles)

Many programming languages have a function for that to do that for you...

In Perl, it's called quotemeta (qw, qq and family, too), in Python and Ruby it's .escape... and there's always \Q ... \E to use...

I'm sure others have similar methods/functions.

Absolutely.

The book doesn't just teach you regex, but the why, how AND the dialects. It gives you an overview over different tools and programming languages and their regex-related functions and methods.

On top, it contains a ton of examples, is very well written (considering the insanely dry and difficult to typeset subject :) and is very polished (I think it's in the 3rd edition by now..)

If you just google or experiment on regex, you usally get bad regex, badly crafted regex, brittle regex and make every single mistake the book prevents you from doing.

It's really one of the most worthwhile books of reading through - it's also an excellent handbook to look things up.

Remember that a lot of commandline tools take in regex too - grep, sed, awk, you name it - it's not just for use in programming languages.

Your favorite editor has regex too.

I simple don't know how people can live without; I'm using regex practically every day.

P.S.: And _after_ reading the book, you will understand why people yell at you when you parse HTML with regex but you will know how to do it anyways and at least not completely badly. ;)

P.P.S: And here's the canonical post to BUT OF COURSE you can parse HTML with regex from stackoverflow.. :) http://stackoverflow.com/questions/4231382/regular-expressio...

THE single best ressource to really learn how to deal competently with regex is still Jeffrey Friedl's book "Mastering Regular Expressions".

You will profit from it for the rest of your career.

(There's also a Regex short reference and a Regex cookbook by O'Reilly...)

You mentioned in passing that you have a feeling that Picasa isn't surviving for long due to it's "old-fashionedness".

Considering how important "usefulness" and "usability" are by now, maybe add a criteria along those lines - how large is the "your mom uses it and likes it" factor, how "contemporary" are the UIs, how much effort puts Google into polishing it (it does a lot with G+ and Gmail for example) - something like this.

Another criteria could be "level of integration" - how much can you use a Google product as a standalone project or how deeply connected is a product into another one (e.g. Picasa used outside of G+) - which might in the end indicate not a direct shutdown but a product's dissolution into another one.

So far I'm just not using the Developer Tools at all, because they don't give me what Firebug does.

Debugger, Inspect and Web Console just aren't working well together, aren't interegrated smoothly into each other and I hardly can get from one to the other. I can't enable ALL of them at once.

If they _were_ like Chrome's tools or Firebug I'd wish for the features of Firebug's XPath and CSS extension: input expression, get matching elements highlighted.

So, either they have to be as useful as Firebug, or throw them out to keep FF lean for users who doesn't need them anyways.

Also "keep the DevTools as simple as possible" makes absolutely no sense to me as a Web Developer - I need those tools as GOOD as possible and as USABLE as possible with a specific range of features I've come to expect from Firebug and Chrome.

I mean, I basically live with an open Firebug during work...

I suggest reading very carefully.

I absolutely believe what he writes, because he's quite precise about his experiment and how he did it and this really works for a couple of reasons:

* This guy isn't 20 anymore. He has actually explored and learned and trained "productivity and focus" which he blogs and writes books about - so he doesn't start like a 18 year old directly from school, unexperienced maybe in this level of focus and discipline.

* He was pragmatic in his goals - very much so. He didn't write "becoming the world's foremost expert in linear algebra" but "passing an exam". And so he did. He also didn't write "passing everything with a top grade" but "just pass, if better - wonderful".

* He actually did his math on "hours to put in" - a semester doesn't take full 6 months, you usally don't attend lectures/lab every day 3 hours a day but 1-2 times a week, 2 (university) hours plus preparation. If you carefully add this up, you actually get a surprisingly low count of actual course/lesson hours.

* Taking in a course in a focused manner is actually quite efficient and helps you (at least it does for me) follow the material without interruptions. You also can repeat as often as you like (he mentions a fast forward and replay button in his TEDx talk) - which btw. makes part of the success of e.g. Khan university material.

* He also put some effort and training into the right way of learning and _that_ pays off massively in terms of speed.

Also, one of the points he is actually making is part of what most of you critizise: Going through the list of MIT requirements is something different compared to "becoming an expert in X" - don't mix that up.

Couldn't agree more.

I already own an N9, which is a beautiful, tasteful piece of hardware in itself - no plastic-y feel at all and I have a Galaxy Nexus, too.

Really, no comparison.

On top, I find the metro UI design very elegant and convincing, I'm actually considering a Lumia. Can't wait to try one in my hands.

Well, this kind of insanity made me step back 10 steps and invest some time (almost a year by now) into the "classics" so to speak.

Inspired by Crockford's talks in which he mentioned a couple of times the lack of history and historical knowledge among developers, I suddenly remembered that I got an education in humanities before I even went into programming and really did start with the classics - Greeks and Romans and Philosophy - and I asked myself why on earth I never really considered doing something similar in computing. (Someone called it in some article I've sadly forgotten the Oxford way - you learn Latin and Math and from there you can learn anything anyways ;)

So I decided to ignore all fashions, new things, upcoming frameworks and such for some time until I got what I would consider (totally subjectively) a solid foundation (not there yet, will probably take another year at least) of knowledge.

I personally decided to define "classics" along the lines of "knowing Unix and its history and concepts well" (re-learning shell and commandline wizardry on top), "understand decent C and Assembler", "becoming familar with the influential languages of important concepts like functional and OO programming (Scheme/Lisp and Smalltalk). This includes really understanding SQL (which I suddenly started to really like to my own surprise). Maybe I add some PostScript and TeX along the way. I also found a new appreciation for Perl's text processing capabilities and its influence from the 1990ies on.

Set aside that I constantly have to fight kind-of a "bad conscience" exactly BECAUSE I'm not hurrying along to try out the latest and greatest new fashion, I'm starting to feel a deep change in my programming skills, in my thinking about design and I'm constantly marveling where computing already has been and how much there is to learn from the classics. I also started to get a distinct feeling of "Man, I just don't NEED all this clutter and stuff" and a newly found appreciation of "simplicity" (Watch Rich Hickey's talk about "simple versus easy"..).

I started to slow down, to think more carefully, to read a lot more on concepts and ideas. I've finished recently Christopher Alexander's Pattern Language book for example to get a better feel for the "orginal" idea or read up on the history of "lean production" and Toyota's influence or looked again at Dieter Rams' design principles (I'm German and I basically grew up with Braun appliances, I didn't even realize how influential his designs have been to me..)

All this changed me and my thinking about programming deeply and made me find kind of a "central theme" or "essence" in programming and design I like and I'm starting to strive for.

In the long run, this also gives me a foundation of how I'm judging new tools, ideas, frameworks and programming languages.

On top of that, I'm better able to place myself into a certain "style" or "culture" of programming I'm not going to give upon as long as I can afford it.

Anyways - I personally think there actually is a choice whether one tries to catch up with everything new or peek into new things selectively or just steps back a little and watches how all this will unfold in the long run.

(I also have a long-held, un-proven personal theory that people simply like _writing_ frameworks a lot more than _using_ them - some are just faster to release theirs into the public.. :)

Yes.

Stability, maturity, great backwards compatibility, whipuptitude, a sea of well-cared mature modules on CPAN, the ease and convience of CPAN itself, already installed/available everywhere, Unicode support, creativity and competence of the community, exceptionally good documentation, "the spirit", MOP via Moose if I want to, rarely gets in my way, scales very well in terms of "thinking" and "project" (everything from tiny admin-script up to full-blown financial district application possible), speed, amazing interesting features in perl 6....

And no, you don't write the same Perl as in 1996 anymore.

I'm seeing the same thing in Berlin these days - tech conferences of all kinds, usally 2 days, tickets ranging from 300,- euros up to 1200,- euros.

Even if employers would send their developers to one of those two or three times a year - how many developers from different countries can even afford those prices? Half of europe simply isn't that rich and doesn't pay nowhere near that high salaries.

On top of the two-days event you'd have to add hostel/hotel and travel (train or flight) - even with my (in comparison) rather high german salary I think twice if I really want to pay several hundred euros for an event of two days.

And conferences don't have to take place in hotels, there's all kinds of venues - some hotter, some less so - one could meet with 50, 100, 500 or 1000 people. Some developer conferences simply take place in rooms of the local university for example. (Usally a not so hot location, ok..)

I would really like to see that developer's conferences stay (really) affordable for _all_ of the intended audience.

Why are so many people making this an either - or?

Yes, I love programming.

Yes, I (mostly) treat work as 501 even though I (usally) love the work I'm doing, but I'm not owned by any company.

Yes, I decide over a job similar to "love" precisely because it takes so much time of everyone's live and I spend more time in the office with my coworkers than I spend with my friends, family and spouses.

And I still want to see something else but my editor (and I do really like my editor :) - art, books, parties, the city I live in - which I also chose by "love" which is why I wouldn't move for a job to a city I do not like - other cities, good food and other people.

So, I look hard to find a workplace I like to do work I love doing which fits into "having a life outside".

And exactly that enables me to have a choice EVERY DAY wether I want to do some hacking privately or have a nice dinner with friends.

But for many life decisions I'm on the side of the 501 manifesto's spirit: I wouldn't leave my family/spouse for a programming job at $glorious_company, I wouldn't move into some boring smalltown and leave all my friends and the opportunities of my favorite city behind just to do programming at XYZ.

This doesn't keep me from having two thinkgeek shirts TOGETHER with 20 others, going to a nerd conference here and there AND take two hours off to go into this cool art exhibit which is at the nerdy_conference_town right now, read a programming book once in a while on top of the pile of other books I read.

I totally accept that I'll never become a rockstar in programming with this life-style - but I might have hung out and gotten drunk with real rockstars on some of the parties I had time to attend or even played some rock because I had time to be part of a rockband. ;) (God, I hate the rockstar metaphor a lot.. :)

In the end it's about looking down on my life and thinking "it's a good life" - and that changes from decade to decade anyways. What I considered a good life with 22 isn't anymore what I consider a good life now - and yet I wouldn't change a thing of my 22-year-old life.

This is so immensely interesting and useful what the guy documented here... and thanks to Mark Erdmann, it's perfectly illustrated.

What you really see here is not just "his progress" but how he actually did it:

* He went back to the classics (greek statues, classic poses, perspective etc) to really learn the ropes

* he practiced over and over again, often the same subject again and again

* even if his taste seems to lie with those scifi/fantasy-style figures, he nevertheless trained to sketch poses, the human body, faces, muscles and so on

* his strokes become more confident year by year

* he needs less strokes on a sketch to make the viewer see something recognizable

* he judges his work repeatedly

* he lived with being a beginner for quite some time but didn't give up

If some of you might remember Douglas Crockford's JavaScript lessons series - he stressed the "knowing the history" quite a lot - quite similar to many "how to become a great developer" howtos stress to know a language like Lisp. (Basically our version of "learning the classics"...)

The same applies btw for what writers documented about their progress and journey to become good writers: "know the classics" and "do it every day".

For the folks interested in the science side of "becoming an expert", please consider Ericsson's "Expert Performance" (Cambridge University Press) - that's the source/foundation of the notion of "a decade" and the "10000 hours of deliberate practice" comes from. (And a very interesting read...)

I'm german - ignoring words I know but couldn't immediately place properly (raggamuffin for example) I got 19000.

My english comes mostly from watching movies and tv series long after I graduated, reading novels, articles, handbooks and later by chatting in english.

Due to movies and tv series, I adopted an us-american flavor of english.

Also keep in mind that this test didn't ask for domain specific vocabulary - if they would have made a section of computer related vocabulary, we probably would have all scored perfectly. :)

That's totally not the point with all our languages these days - Ruby, Python, Perl - next year JavaScript will probably have a similar ecosystem of modules as we do as productive as the community writes code. Who doesn't have some amazing web framework these days?!

The differences boil down to details, architecture, stability, speed, security, documentation and the like - but seriously, do you really think some route handler in _programming language_ X or Y does make _any_ difference?

I personally didn't like the philosophy of RoR - I liked Merb better and got really put off by its community (and still am) and specifically by blog postings selling me shit as gold and all this "awesome <insert some simple basic not even well crafted solution to an every day problem here>" selling - but this is a matter of _taste_ and _personal preferences_ and don't really count as an argument.

Of course you can write a damn DSL in Perl in any way you like - otherwise a project like Moose wouldn't even be possible which wrote an entire metaobject OO system in Perl.

My point was that people usally plainly don't _know_ about those things and blindly think that PHP is the only language you can do "Web" with, Ruby the only language to write a DSL in and Python the only language well I have no idea what Python might be the only language for. ;)

This is bascially what I was talking about.

Though the Ruby community managed somehow to drive off _why and someone like Zed Shaw if I remember correctly. If that really appeals to you...

Err.. yeah - what do you think after whom gems etc. are modeled? :)

Haskell's system is called "hackage" for example and "R" has its "CRAN" and so on.

Though it's really no fair comparison as CPAN contains what.. 89033 modules? http://search.cpan.org/

Well....

How about Django, Evently, Moustache, CLOS, Hackage, Sinatra, Merb, OMQ as acronyms? ;) (None of it Perl..)

Anyways. CPAN _is_ the killer app. It's a HUGE, extremely easy to install module/library archive. Perl's modules aren't spread around everywhere but neatly and nicely collected there and you just do a "cpan Foobar" and get Foobar with all possible dependencies included.

Which is something what many languages (some still don't) have these days one way or another but really nothing compared to CPAN in number, service, search, testing facility and so on. You plainly _never_ have to bother searching your ass off to find some library you might need.

Moose is Perl's OO system - as with JavaScript you can do different OO styles with Perl and Moose is a framework to do a role/trait based (please see Smalltalk for details or Perl 6's spec) OO with a heavy twist on metaprogramming.

Perl is for writing things like Amazon or the IMDB and keep it running for 12 years in a row or for creating Nagios and SpamAssassin to watch over half of the Internet. Thanks to Perl, everybody can easily imagine what push, pop, shift, unshift on Arrays/Lists does and thanks to Perl everybody has very shiny Regex these days. That's why Vim has a magic/nomagic flag and what the P in PCRE stands for. The Ruby world gladly thanks Perl's DBI after which it modeled its own database interface.

That's what Perl is about. Sharing shiny features and establishing a culture of "getting things done who run really fast".

Sure, there are plenty of reasons of the whys and whens - on the other hand, we could easily ask "why didn't everyone choose Emacs when textmate's development came to a halt" or "Why didn't people choose Python as their web language of choice when they didn't like PHP" or "Why not Bazaar instead of SVN" or why Ryan Dahl chose JavaScript as a base language for Node.js and not any of Python, Ruby, Perl, Scheme, Lisp or Lua - but JavaScript - and so on. (As others already pointed out below so I'm summing this up in one sentence here..) Thankfully we have plenty of options to choose from nowadays.

And yet I'm still convinced that the choice of Git over Bazaar has something to do with the smoothness of Github and with "It's from Linus!", the choice of Ruby/RoR with the image 37signals so nicely projects, that JavaScript's recent rise and massive change in perception comes thanks to Douglas Crockford and Erlang would have probably stayed in its niche if it wasn't for CouchDB.

So I was surprised and amazed by the change in perception of Vim over the last year and therefore I blogged about it.

And yes, along your examples Perl faced a similar situation around 2000 (so thanks for the well chosen examples) and decided to do Perl 6 to re-ignite the Perl spark. (Let's set aside for a moment wether or not it worked and what happened after that and boy am I sure the second I hit the submit button people will _exactly_ totally get into this subject.. ;)

I also didn't ask wether or not one really wants the success of the masses or if it might be a good thing to stay in a well-defined niche with a community of your choice, creating your own culture - as for example shows the Linux distribution Slackware very happily year by year and to a great satisfaction of its users.

I also didn't mention how much it might have to do with the age of developers, wether some changes plainly might be a generation thing of "first generation web developers" and "second generation web developers" or how much Apple's regained success does play into all that.

But as we can see within the comments below, old Perl cliches aren't really dead and get repeated all over wether or not the subject was Perl's marketing and not Perl's qualities (or the perceived lack thereof...)

Or maybe we all get kicked our asses by Lisp next year - thanks to Peter Seibel's Practical Lisp Programming book or "Land of Lisp" and of course Paul Graham and Emacs wins all over. ;)

Learn both of it. And C is something to know anyways.

Fun in programming is about doing different things, exploring technology and deliver a well-rounded project.

Also, you chose another field which is rather heavy on the GUI side - you will soon realize that ALL GUI done right isn't really something done effortless. It takes much work. Everybody wants to USE good user interface (be it GUI or command line or API-wise) - but few people really like to CREATE them...

And: Web GUI and developing for tablets/touch-based devices are really just two sides of the same medal - what if you need to make a tablet/touch-able Web GUI?

Accept that browsers are strange beasts and get it over with with good frameworks and you'll be fine.

Or choose the middleware or database-side of Web programming - also two good options.

And also learn that "6 months to learn X" literally means nothing in the programming world - there's ALWAYS a "6 months to learn X" ahead of you. Even if you already know a handful of languages very well, have 2 decades of well groomed experience - there's always a subject you know next to nothing about and 6 months isn't really a long period to learn something fundamentally new to you.

Those 6 month will never go away and there is no point you're working yourself up to and then just stop and "be a programmer" :)