- New: when viewing completed downloads in the flexpane you can open the file in its default application by holding down the shift key and clicking, with great flourish, upon the desired location.
- Fixed: a vile bug that could corrupt cache files if your Mac shut down or restarted unexpectedly while Slack was running.
- Fixed: a bug that would show greater than 100% completion of file downloads. This was not a useful area for overachievement.
- Fixed: A bug causing an erroneous zipper issue, automatically decompressing gzip files after they were downloaded has been totally repaired.
- Fixed: a bug that could leave you staring at a blank white window after signing in to a team whose session expiration time was set to zero. We now process the login result using a slightly larger value of zero. If you experienced this zero or less than zero times, congratulations. If you experienced it more than that, apologies, there is zero chance of you experiencing it again.
Stagefighting requires mad skills: it's a domain. But a great swordfighter/MMA fighter/etc. is not necessarily a great actor.
Some domains are math/physics/etc.-intensive. Developers who work in those domains need all those skills. But they aren't enough to make for good software.
3. Here are a couple of quotes from the conference:
"Agile software development is people-focused and flexible." - via @DanaPylayeva
"Software processes which separate out design and construction are fundamentally untenable, unlike building a bridge, building electronics, etc. [Fowler] The manufacturing metaphor was broken from the very beginning. Assemply lines are optimized to produce many of the same exact thing. With custom software, you only ever build one." - via @GetzTweetz
People-focused, flexible, custom - these are aspects of software that are seriously distant from anything we associate with engineering.
4. Software itself is orders of magnitude more malleable than what engineers deal with. We're essentially working with pure Categories, magical atoms of Platonic ideal forms.
5. I've worked with engineers and physicists who fled their abysmal labor markets for development. They knew a lot about the domain, but next to nothing about software. Don't get me started about the code I had to salvage....
My current title is "Software Engineer in Test". I'm part of a QA team, looking for ways to improve their process. I'm actually writing tools for the dev team. It's a long story.
Anyway, I've had titles with "Engineer" in them many times in my long unillustrious career.
But I've never really been an engineer.
I didn't want to have to write this now. I want to go to bed so I can get up at 6 for my hour's commute. But I twote a hashtag and I think I insulted somebody, so I have to clarify. 140 chars won't do the trick.
The hashtag: #DevelopersAreNotFreakinEngineers.
Developers with any aspirations to Agility shouldn't want to be considered engineers.
Here's the beginning of an outline of what I mean:
Engineers can count on settled/established mathematics. Developers are barely grasping at the rudiments of the math behind what they do (best bet is Category Theory IMAO).
Engineers work in well-defined domains with settled/established natural science behind them. Some developers work in these domains, but I don't want to call even those developers "engineers".
Developers deal in an infinitely more plastic medium than engineers.
Engineers are almost always members of BDUF/Waterfall organizations. The engineers that tried to stop the Challenger launch because they knew the O-rings could freeze were overruled by management: their expert opinions meant nothing in the face of deadlines/PR/etc.
Developers want to be called engineers because it's respectable. It's like wearing a dashing uniform. It's professional. Maybe we'll get paid more....
It was a technical screen led by an architect at a company that billed itself as Agile. We started out with a general conversation about good OO practice and Agile development.
Then he asked me about HttpRequest. I described its general behavior, but I had the feeling I wasn't satisfying him. It had been close to two years since I worked with a Java app that used HttpRequest.
Later the recruiter who had set up the screen called to say the interviewer loved what I had to say about OO and Agile and admired my passion, but felt I didn't give enough detail on HttpRequest, so they were taking a pass.
That's what I call a policy of certain agencies or individual recruiters whereby candidates are told that if they are sent on an interview they must commit up front to accepting an offer in case one is made.
What makes this lock-in asymmetric is that the client company is never committed to making an offer in the interview.
This is problematic because one of the fundamental tenets of "free enterprise", as we are all taught from birth, is that the relation between an employer and a human resource (formerly a "person") is one of full equality and symmetry. This is why unions are unnecessary, as we are constantly being told these days.
I can understand if recruiters are chasing commissions or points or whatever that they want some guarantees when they spend time on something. I'm sorry, but there are no guarantees in this business: free enterprise is about risk. But I will guarantee that if I find out there's a policy of Asymmetric Lock-in, I'm not playing.
Development is an attention-focused activity, and for me at least, a sense of closure is important for that focus and important for morale.
And for me, this is yet another example of the critical importance of rhythm in the development process. XP is a hierarchy of rhythms, from regular releases through iterations and daily standups down to the Red-Green-Refactor cycle.
But it's not just XP: every developer who hasn't burnt out develops some kind of rhythm. In an environment based on an ideology like Waterfall that's seriously disconnected from reality, corruption is inevitable, and the developer's personal rhythm is not going to be good for the project. I've run into this on my current project, which is "corporate Agile" - i.e., largely about daily standups. I've tried to convince team members with no real Agile experience that TDD is personally satisfying. Many of them don't buy it, not for intellectual reasons, but because it's completely contrary to their own rhythms, which involve writing a lot of code, building up the tension, and then manually testing it, which provides the release. It leads to complex and overengineered code that's nearly impossible to create automated tests for.
I think Kent Beck's most original insight about development was that it's done by humans, not machines. (Okay, so it wasn't that dramatically new - Weinberg brought psychology into the methodology conversation, even if it was based more on an abstract ideal than a felt reality.)