benaston

Companies complain and complain about the hiring process, with people like the OP even resorting to subversion in an attempt to "de-risk" the process.

"The only real solution would be to get to know the people better..."

I totally agree. Read the resume/CV, run the technical test (if required), conduct the interview. If they seem good enough, hire them.

All the jobs I've ever had (perm and contract), had a probationary period during which I could be fired at will.

If a company cannot handle the financial strain of hiring and subsequently firing someone within the probationary period then perhaps they shouldn't be hiring someone in the first place?!

>> most things behave the same in IE8/IE9 as they do in Chome, Firefox and Safari

Having recently developed an HTML5 single page web app, I can assure you that this statement is utterly false.

Agree wholeheartedly with this post. Thing is; I have never come across a so-called user experience expert that had a single particularly insightful thing to say about a user interface.

Indeed, my experience has been that I get more insight from "lay" people than these guys.

I can't even be bothered to count the number of different items on the Google menu. Actually I just have... it's 17 items (for me), plus an "even more" item. I'd love to see the analytics for that one!

Now, you might forgive them because, well, if you have lots of products then you need a way to navigate to them... EXCEPT the millions they spend every year on making menu-based navigation completely redundant by their world-beating search.

If I want Google Maps, I will either type "maps" into Chrome's address bar, which auto-completes it, OR (as most non technies will do, I hazard a guess) I will type something (e.g "maps") directly into Google.

The unfortunate thing is that this is not just Google. It 99.9% of websites I have ever visited. OK, so most small companies do not have the resources for a dedicated UX person, but the only big-company website I can think of with a sane UX is Apple. Is it really all that hard? Actually I suspect it is - it's Conway's Law in full effect.

This is a real problem in the industry IMO. You do not need to be a good algorithmist to be one of the outstanding programmers in most industries. You just don't. The most important contributor to being a good programmer is excellent interpersonal communication - something that is unfortunately actively filtered out by many interview processes.

Take SOAP for example - that whole "bag of hurt" was created due to a lack of communication between developers (those who created HTTP and those who were developing web-based RPC (i.e. SOAP).) The accidental complexity of SOAP versus the more effective REST (leveraging the existing HTTP platform) and the problems that come with the inner platform effect have cost the industry millions (if not more.) I'm sure SOAP had some super smart guys on the team, but it took them years to speak to someone on the HTTP effort earnestly enough to realise they were replicating features of the platform they were building upon.

Or take XHTML vs HTML5 vs HTML 5 (the space before the "5" is important to the W3C apparently.) Just google for discussions about the rift between the W3C and the WHATWG - to me it smacks of "geeks" (and I use that term perjoratively, knowing that I am a geek) not communicating properly.

Finally: on spec, on time and on budget software development is far, far from a solved problem. There are so many knarly issues in most organisations - code maintainability, code testability, development process, effective test writing, refactoring, release mechanisms, team work, navigating politics... naming, even.

All this, before you worry about whether to use this library (and it usually will be a library) or that because of a slightly different algorithmic implementation.

We need the algorithmists - but we also need the guy who can break bad news to the project office, the guy who can construct beautifully simple object models and the guy who really knows what testable code looks like.

These are all orthogonal skills.

I always wondered what the purpose of Path really was, given that it offered little over and above Facebook itself (apart from an arguably nicer UI.) It would seem the purpose is to data-mine users' handsets.

Uninstalled Path. Incredible violation of privacy.

Certainly, but the inertial scrolling on OSX actively encourages flicking as a mechanism to scroll a long distance. A genuine feature IMO.

…except, if you happen to be in a browser and at the far left or right of a page, then a big context switch suddenly occurs and navigational action is performed, potentially losing valuable state.

The use of two finger "flicking" is unnecessarily overloaded. Apple can solve this by making 3-finger navigation the default.

"countless usability studies" References?

Not at all. The behavior in Lion (inverted scroll movement, bouncy scroll edges) encourages the user to see themselves as actually touching and directly manipulating physical objects on the screen (cf iPad/iPhone). One such resultant user-behavior is "flicking" to quickly perform the scrolling action.

If this behavior is overloaded with a navigational function, the user now may very well accidentally invoke the navigation function with a flick and lose data (HTML form data for example.)

This is a genuine usability issue that needs to be addressed by Apple.

Overloading the horizontal scroll with page navigation is a bad idea, and although hyperbolic, does, in my opinion, break the web. Apple should change the default behaviour to avoid the overload. I am developing an app using horizontal scrolling and hadn't noticed this particular issue before unfortunately :(

IBM constantly seems to release press releases about technology it hasn't yet developed to production quality. Said technology always vanishes without trace (as far as I can recall.) I'm not holding my breath on this one.

If the job stays open for months then either the role isn't that important, or the hiring company is doing something seriously wrong. Finding good people is not difficult ("site:linkedin.com works for x", where x is google, facebook, whatever). Attracting them is harder - either the company needs to sort itself out internally to meet candidate expectations or it has to modify its business model to pay the expected wages.

This is all bullshit. Each company pays what is profitable for its business model. Work in a hedge fund? Your pay is commensurate with the business model. Work in a digital agency, likewise. As far as I can tell a digital agency is a digital agency, is a digital agency. They all work the same market with the same overheads. It doesn't matter that the dev in the hedge fund is doing precisely the same job (in my hypothetical scenario).

"You are paid a little better than someone with your same job in your geographical area."

Of course you are, otherwise your employer wouldn't be in business. The operative word being "little". Substitute "a lot" and either they have a disruptive business model and are willing to pass on the cream to their employees (unlikely), or they are going out of business.

Give me any dev in any city in my country and I will be able to tell you what they are on based on their seniority and sector plus or minus a few grand (and what's a few grand after higher-rate tax?).

Tldr - this policy is moot because salaries are open secrets.

FWIW, if you want to earn more go into contracting (i.e. take on more personal risk), move sector (i.e. go into finance), start your own company, or move into a more traditional profession.

Please accept my apologies, my original response was a little OTT. The objective reasons for making the switch are:

- its a lot faster (IIRC creating a branch in subversion is the same as a copy operation) - the merging algorithm is better (this is so important IMO) - you get to commit when disconnected from the network - because it is faster and uses significantly less space, you can improve the way you segregate changes, giving you more (and improved) options when it comes to your branching strategy

Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space for branches. Creating branches is much quicker due to a fundamentally different way of branching. Finally, it has a killer app in GitHub. What more do you want?

In this blog post, the author is reifying concepts and improving separation of concerns(1). This is basic software development. Which makes me wonder why the OP got the impression this kind of thing was "secret"?

(1)The usual warnings about premature optimization apply.

The iPad provides the ability to connect an SD card, which fulfils a similar use case... but discounting the iPad, OSX Lion takes steps away from the filesystem, with all the files openable by a given application visible a la coverflow with a flick of the wrist. It also does away with the saving metaphor in many apps, further distancing the user from filesystem concerns. In light of this, it would seem more a matter of will than being "too hard" or "pie in the sky".

"...write code..." Congratulations, you are part of the less than one percent of the world workforce that are developers. As a developer, even I only need full filesystem access when I am developing, which is a fraction of my time. Having full filesystem access is an important use case, you can have it. For the rest of the world, it is a usability barrier.

Files without a dedicated application will be the exception rather than the rule. Movies, Photos, Documents, spreadsheets, databases, music, books; you will usually open in a dedicated application. It's not hard to envisage an improved UI for files that do not have a dedicated application: they could be presented in a view showing all the files that are not associated with a program, for manual association. From then on, the system would know which file types to present along with that application. In addition, it goes without saying that full access to the underlying file system should be possible for developers and those that need it (which will be a tiny fraction of the userbase).

Maybe I was unclear in my earlier comment. The best way of implementing file handling is likely some full full-featured filesystem under the hood. My point is that this can be abstracted away to something more user friendly than a tree containing hundreds or thousands of folders and files. Transfer off a device obviously needs to be considered, but exposing a device (e.g a USB drive) as a hierarchical filesystem is usually unneccessary (and, IMO, counter productive from a usability standpoint).

Well, I can't disagree with your anecdote regarding complaints (although I have owned both iPod and iPad since they were released and have never had a problem beyond the iTunes file transfer flow being awful), BUT the constraint to the Apple ecosystem and the iTunes flow are implementation details orthogonal to the actual hiding of the filesystem (i.e. it is easy to see how Apple could make file sharing easier without introducing the concept of a filesystem).

No, they do not need to know about the filesystem. Take the iPad or iPod as examples. They have full-featured applications and the filesystem is invisible.

Users do not know what a filesystem is. They don't want to know. Whilst the improvements enumerated here are undoubtedly improvements it's all lipstick on a pig. It's time for the hierarchical filesystem to die.

Frankly this is a good example of over-engineering what should be a non-problem. In the vast majority of cases the option I want is "keep both" - this reduces the chance of data loss to zero and enables me to get on with something that is more important to me at that moment (and use my excellent human brain to delete one of the conflicted files later). As soon as the UX designers attempt to do anything else the UI becomes very complicated, very quickly (as shown here).

One final point - from the linked article it would appear that the Windows UX designers remain addicted to modal dialogs which are, IMO, the antithesis of a productive UI.

>> It really confuses to see kids with red bulls typing code all day and night

Those kids are learning and will probably make a success of what they are doing. The payoff comes later.

Oh yes. The whole movie industry needs to change. When a new movie comes out I want to see it that day, on my laptop/TV/home theatre in HD. If I am constrained to a single viewing for a period, fine.

I do not want to see it in a smelly, sticky, noisy public theatre.

Will this ever happen? Unlikely.

Well, if you want to use this provoking analogy, then I disagree. Recruiting for a company (whether that be a startup or any other) is like selling crack - you hope to make massive profits by taking advantage (long hours, low pay) of other peoples' dependency on you (not enough savings/skills/personal commitments/psychological barriers to move elsewhere).

I also agree. There are so many fundamental issues with Windows that do not seem to be being addressed such as

- the entire desktop metaphor (tired, outdated, can be improved upon)

- the entire hierarchical filesystem metaphor likewise

- application installation

- the registry

- WinSxs - seriously, take a look at how much space this directory "wastes" (increasingly important with virtualisation and SSDs)

- the start menu - it's not useable, honestly

- ribbon UI (don't even get me started)

- the whole look and feel of Windows (more akin to Fisher Price than polished glass and aluminium)

- the quality of bundled applications - notepad and paint - seriously? in 2011?

- I could go on and on and on. If it weren't for the quality of the .NET stack and the jobs market for .NET I would be on Linux/OSX in a flash

IMO, Windows merely reflects the beuraucratic uninspired organisation that creates it. This will never change, so really, I shouldn't get so upset, but I have to work with this goddam OS, so it grates a little.

The OP states that web dev is overly complicated and broken. I counter that modern tools are far from being broken, and are infact lightyears ahead of what was available only 3 or 4 years ago. Not a refutation per se, but a counterpoint.

* elastic compute - easier - no need to worry about hardware * REST - easier - no need to worry about WSDL and XML * HTML5, CSS3 - agreed powerful standards to create create UIs * jQuery - much easier than hand-rolling * JSON - easier and lighterweight than XML * decent modern browsers - improved standards adherence, so easier and quicker to write for multiple browsers * NoSQL databases - easier to work with (no ORMs), quicker to set-up (no schema) than relational dbs

If this post was written 3 or 4 years ago I might be inclined to agree, but with elastic compute, REST, HTML5, CSS3, jQuery, JSON, decent modern browsers and NoSQL databases we really are in (or are very close to) a pretty good place IMO. If the OP is complaining that he needs to know a lot of technologies to construct a website... well, I think that is the nature of the beast and falls out of the de-coupled nature of web-apps.