For a senior developer, $150,000 is about right. I'm looking at the latest half dozen jobs I've seen on LinkedIn for open senior developer positions and they all start at that number, and range up to $185k to $200k. Digging a little deeper, I see some th atstart well above that number, but it's for the huge companies you're thinking of -- Google, Netflix, Github.
Time to broaden their hiring pool then, $150k is double the cost of a senior developer in many other parts of the world (yes including English speaking first world countries).
When you've got 90 days till the doors close you cant be picky about your hiring pool.
Read the posting. They dont have money for a team, they don't have money for a senior developer. Whether $150k/FTE or $75k doesn't matter, because they don't have either of those.
Once the server and other costs have been paid, the have money for... maybe a part-time junior in Cambodia.
The claim is that 150k is the baseline that is often exceeded. I don't know the region you're looking for on LinkedIn, but what I see for European jobs is that they barely crack 100k for developers. At least the senior, non highly specialist, jobs I'm seeing.
Sadly, they're not popular in the U.S., but I love them. I switched my comics reading habit after nearly 30 years to European comics and haven't looked back. I prefer Asterix over Tintin, but I think reading Tintin with some of the historical background in mind might help. One of these days...
For anyone in North America looking for European comics to read, I review them at PipelineComics.com - there's something in European comics for everyone, from humor to action to drama and everything else.
Asterix is more aimed at children, compared to Tintin. Also, one of the best/funniest parts of Asterix is the constant wordplay, which often does not translate well (though the translators do try).
And the series is still going -- the latest book in the series just came out last year. Cinebook is publishing English translations of the series, too.
Wow, that brought me back, thanks. My final project in my college computer graphics course was a Boulder Dash clone from the version I had on my Commodore 64 growing up. I brought in the C=64 to compare and contrast the two versions. Wrote a level editor and everything. It's still a fun puzzle game.
I loved this episode when I first heard it, but reading your recap of it reminds me of a similar story from my college days. I had a CompSci professor who had worked at Bell Labs, which was all of 10 minutes down the street from the college. I remember he was having problems with printing something in the computer lab one week, so he wrote a driver for the printer over the weekend. This would have been about 1997 or so. And he talked about it like it was nothing, the simplest thing in the world.
It looks like my professor was just taking after the people he worked with. For that level of programmer, writing new drivers for hardware was a weekend project.
One of our CompSci textbooks was written by that same professor -- I just took it down off the shelf and looked at the intro. Brian K. was thanked for being an early reader of "several revisions."
In retrospect, it's really cool to have been only a couple degrees away from that kind of history -- and I probably didn't quite realize how awesome that was back then.
The thing is that writing a printer driver was quite close to being the simplest thing in the world back then. :-)
I remember that when a friend first introduced me to Linux around 2002 (we were both high school kids), I ended up writing a rudimentary printer driver as the printing support in Linux required installing 250MB worth of packages that I simply didn't have enough space for, as I had installed Linux to a 1GB partition that I got after squeezing the Win98 on my father's laptop into 3GB. I used Red Hat Linux—not the most minimal distro but I had no idea what I was doing. So when I wanted to print something and couldn't install the printing packages, I grabbed the paperback printer manual which described all the low-level commands the printer supported, studied it to find the commands I'd need and then wrote a simple program that took an image and sent it to the printer. It couldn't have been longer than a few hundred lines.
The printers back then were simple and came with real reference manuals that documented how to communicate with the printer, so you could really write a simple printing program/driver without being a UNIX legend (I am not).
A lot of what Blow says is not entirely accurate. For example he presents a simple picture of declining software quality over time, but anyone who was around at the time knows that both desktop OSes and desktop applications (including web browsers) were certainly much more crashy, and probably more buggy in general, than they are now. Likely quality has started to decline again over the past decade, but it's still not remotely back to where it was. It's hard not to suspect that Blow passes over this because it tends to contradict his "higher-level languages and more infrastructure → declining quality" argument. Section 7.4, "Programming Environments Matter" http://philip.greenspun.com/research/tr1408/lessons-learned.... of Phil Greenspun's, apparently, 1993 SITE CONTROLLER dissertation https://dspace.mit.edu/handle/1721.1/7048 makes the same "we don't expect software to work any more" lament which Blow delivers at 22:17 https://youtu.be/ZSRHeXYDLko?t=1337 :
> Another reason the "horde of C hackers" approach has worked remarkably well is that, although the resultant software is rife with bugs, most users have no experience with anything better. When an MBA's Macintosh Quadra crashes due to a C programmer's error in Microsoft Excel, he doesn't say "I remember back in 1978 that my VAX 11/780, with only one tenth the processing power of this machine, had memory protection between processes so that a bug in one program couldn't corrupt the operating system or other applications." Rather, he is likely to say, "Well, it is still easier than using pencil and paper."
but places the blame on a switch to lower-level languages and runtime systems. The improvements on the desktop over about the '00s seem to be attributable to (not an expert) the mainstreaming of, and continued development of, the WinNT and OS X platforms, increasing use of memory-managed languages and/or more recent versions of C++ in applications, and adoption of online crash-reporting infrastructure (though probably also increasing use of increasingly effective error-detection tools, which I assume Blow is fine with as they don't create a runtime dependency). So it certainly seems that Greenspun is more correct than Blow, which is certainly not to say that adding more layers of infrastructure has always been an unqualified good.
Also, Blow's talk has a very '90s focus on crashers, error messages, and the like, but many of the worst regressions in software over the last 10 or 20 years don't manifest as crashers or other straightforward bugs at all; and when they do manifest as bugs the bugginess is often intertwined with architectural issues in a way that makes a bug-hunting mentality relatively ineffective. For example, the pinnacle of WYSIWYG rich text editing was probably about Word 4 for Macintosh, which was a slightly awkward but workable mating of stylesheets to the WYSIWYG UI. Unfortunately it was something of a local optimum: further progress on the problem largely requires serious developer thought and/or further user education. So everyone more or less decided to instead pretend that rich text is a solved problem, and things have largely been gently regressing since then. Which is probably part of the deep background to the GMail rich-text jank Blow complains about at 23:47 https://youtu.be/ZSRHeXYDLko?t=1427 . “We can not solve our problems with the same level of thinking that created them”, as Lincoln said. ;)
That was a shrewd marketing move by a developer to get his app blocked by Apple so he could make hay on it. Unfortunately, it paid off. The app shot up the charts after they manufactured that controversy for all the free publicity.
Dancer2 is also great for creating a web service, of sorts. Need something to send out JSON chunks with a URL front-end? Very simple to set up and get going. I've been translating some code I wrote for web pages into little engines for Dancer2 to run for other groups inside the company to extract information out for their own applications. It's perfect for that.
Was introduced to Perl in a programming languages course in college in 1996/1997. Brought it to my first job, where it gained fame there for being the language that took a 12 hour process and ran it in less than a minute. (They had originally been trying to parse a huge log file with Visual Basic, I believe it was. Perl was made for, well, extraction and reporting...)
Been programming in it full time ever since.
Thanks, Larry Wall, Randall Schwartz, Brian Foy, Nat Torkington, Tom Christiansen, Damian Conway, etc. etc.
Count me in as another person introduced to O'Reilly via "Programming Perl." Was "Perl Best Practices" the first such "Best Practices" book?
Well, perhaps one can treat my comment as good part fondness/nostalgia.
Although, I clicked through the pop-up link, to find a fairly brief and limited set of points in a short, single critique of the 4th edition.
I don't know... It's been a while, but I still remember "Programming Perl" as providing not just the what but a good dose of "why" and context.
A lot of people who "don't like Perl" don't seem to understand that, where it's coming from, both philosophically and systematically (if that is a word and I can use it here).
"Programming Perl" is not, in my opinion, a beginner text. Randal took care of that contemporaneously with "Learning Perl". But it was, and -- current shortcomings aside -- perhaps still is, a good post-beginner text.
It also remains "timeless" for me, in that it was a good, engaging read. In my opinion, more texts should -- if clever enough to -- dialog with the reader rather than spewing at them.
Anyway, I don't mean to put myself in the position of defending Larry et al.'s tomb in this post-post-modern world. I'm hardly qualified to begin such a task.
But even if it's not currently the best reference, or even recommended as such, I think it may remain a decent example of how to write one.
> I think it may remain a decent example of how to write one.
No contest. I'm just worried that, with many people mentioning the "good old books" (which by now are simply bad), without mentioning the current good ones, more newbies will try to get those old books and learn from them and get themselves and others in a lot of trouble that way.
That's why i comment to explain and point out alternatives.
I think I ended up with a (legitimate) ebook of the 4th edition, but I haven't tried it.
Newcomers should understand that Perl is beget of its *NIX heritage. With some understanding of this, it stops being "line noise".
Perl was the language I encountered that "thought the way I do". For those considering, I think this remains a very relevant factor in its continued existence. For what that's worth.
"Programming Perl" was the first computer "textbook" I ever read with a sense of humor. Before that, it had been all dry C books and the like. That's why I liked it so much. Yes, "Learning Perl" would definitely be better. At the time, I wanted both the tutorial AND the reference book, so that's what I got.
"Intermediate Perl" is still awesome for the next level stuff, particularly with all the references and transformations, et. al.
reply