When I leave here in 2-3 years, will it be because of the people, or because I haven't gotten a raise and/or promotion?
11 karma · joined May 17, 2015
Back in 'teh day' when my icons were all cutesy skeuomorphs, my computer came with maybe a dozen apps and most of them were on my desktop. Now, I have over a hundred sitting in my global Apps folder alone - never mind user Apps, sub folders, etc.
This gets compounded even more on phones - on my iPhone, I've accidentally placed 1Password next to the Settings app - both have a grey background with a circular center. Settings' center is grey gears, 1Passwords is a blue ring with a keyhole. On examination, they're not similar at all, but I can't even begin to tell you how many times I clicked on when, meaning to click the other - even _knowing_ the differences and kicking myself each time.
I think a lot of what the designers are trying to do is create an icon that stands out visually, and is easily found from amongst a large set of other icons, rather than trying to impress upon us what its functionality is from a metaphor.
What I've been doing instead is using the rsync-ssh plugin https://github.com/davidolrik/sublime-rsync-ssh
I keep a local copy of the repo, which allows me to work even without access to the cloud dev environment and makes searching orders of magnitude quicker, but still saves changes to the remote environment whenever I save a file in Sublime.
It's not perfect, but works well enough for my current workflow, so thought I'd share.
While it does give us some visual information about the birth of cyborgs (using a female body, causing the mental conflict of finding a cartoon robot 'sexy'), there aren't many movies that will take an almost four minute musical interlude showing random city scenes and the rain falling...
I think it ties in perfectly with Kusanagi's introspection, her pondering on exactly what she is, what the 'ghost' is, etc.
I don't think any of it is wholly original - from Neuromancer to Blade Runner, but it definitely stands on its own as a beautiful film.
https://en.wikipedia.org/wiki/Emerging_adulthood_and_early_a...
If you believe that, I've got a bridge I'd like to sell you... Eh? Eh? See what I did there?
Agile only makes complete sense when you take it in its historical context as a reaction to other methods, not as a standalone methodology with no history that sprang wholesale from the ground. It's not "this sounds good, let's try this", it's "we tried the other way and it did not work, we need to do something different".
Saying that you have something that works (an MVP, for instance) is _more important than_ documentation. That doesn't mean you shouldn't have documentation. Documentation will always lag behind actual code unless someone is full time updating documentation, which I have yet to see happen anywhere.
And even if you have documentation - it is an agreed communication of intent. The problem is, not everyone is necessarily reading it in the same way, or communicating their intent very well, or realizing inconsistencies and hurdles in what they've communicated. So when you actually have to write the software - you find you can't do it the way it was proposed, the way it was proposed is less efficient or fault tolerant, conflicts with other parts of the design, or is just ambiguous in a way that causes the developer to code up something other than was intended.
In a waterfall design, you wouldn't find out about the ambiguous bits until you present it to the client - at the end of the cycle when it's quite possibly already too late. In an iterative development cycle you can get constant feedback and more easily react to change. That's what agile is really all about.
Change is inevitable - agile attempts to recognize this fact and work as quickly as possible to create a product and immediately and incrementally improve upon it, keeping things moving forward, rather than spending huge amounts of time fussing over details that maybe won't make it into the final product while missing huge discrepancies or 'unknown unknowns' that aren't well understood until something is actually written.
For me as an interviewee, to have to devote hours of my time doing work for free just to prove that I know how to code, all based on a short phone call, is just as crazy. How do I know your company is one I want to work for? How do I know you're offering the salary and benefits I need? We haven't gotten to that part of the conversation yet and I'm already putting in real hours of work - especially if I have multiple interviewers that ask me to complete code challenges.
It's a catch-22 really. If you have no hurdles, you hire people who don't know what they're doing. If you put too many hurdles, you scare off the folks who don't want to waste hours of their time proving they know the basics. For an interviewer, it's best to get this stuff right up front so you can more effectively screen, but for the interviewee it'd be best that this comes at the end of the process when they know they actually want the job.
All in all, I think this works better for junior level positions because that's where you want to know where folks are at, but hiring senior level people with years of experience, it just gets insulting to have to jump through hoops at every single interview. Of course, I'm a bit burnt out on interviews at the moment, so take that for what it's worth ;)