I work on the team with OP. It's worth noting that in our actual retros we always discuss things causing friction & drag. All of the congratulatory stuff is done out-of-band in an email sent out after retro.
To your other point: are we celebrating mediocrity? I don't think so. While the things we call out may not fit your definition of "extraordinary", when the main discussion points are around how you can improve, it is important to celebrate wins, even small ones, to see how you have improved.
For the last few months before I stopped doing Ruby full time I was using a workflow (on OS X) in which I downloaded a binary Ruby build (the one rvm uses when you do "rvm install --binary" on OS X) and extracted it to "/opt/rubies/2.1.0". I created a script called "activate" that exports the environment variables necessary to run Ruby and placed it under "bin".
Then for each project I would copy the entire ruby installation to my project root in a folder called "vruby". To load ruby for that project I would run "source vruby/bin/activate". It would setup all the environment variables with GEM_HOME pointing to a ".gem" folder under the project's root. Therefore gems are isolated to each project. To unload, I just close the terminal.
The vruby project automates this workflow, by installing a binary ruby using Traveling Ruby and symlinking it to the local project using GNU stow. The plan is to eventually support multiple Ruby versions and more platforms than just my Linux box. Unfortunately, I no longer do Ruby full time and don't have the bandwidth to make it as robust as I'd like. If you like this solution and need help setting it up, don't be afraid to get in touch.
I'm having this issue as well. I deleted all digicert certificates from my keychain just in case. Still couldn't get to Github. I can get to the DigiCert Root Certificates download page, but it gives me an invalid certificate warning. It looks like the same issue as Github.
I really, really don't feel comfortable downloading a ROOT CERTIFICATE with an SSL warning on the page. Who knows what could be compromised in this case?
I'm going to try a couple other things first; I'd like to hear from a security expert, should we find this scary or just a small hiccup?
I had an outstanding OSX update, installed that and rebooted. One of the two fixed it for me. Note: I DID NOT have to install the the root certificates, and if anyone else gets an SSL warning from DigiCert's root cert download site, I strongly recommend against downloading anything from there.
I've found that working like this is making it much easier to provide the best solution for my clients. I can identify risks faster and change on a dime. It's been a breath of fresh air so far, but I'm curious to hear what others think. (disclosure: I work at the company that published the post).
All the jobs I've had since college have had an open workspace. Of those, 3 stand out as particularly pertinent to this topic.
At Job 1, a consulting company, we had an agreed upon culture of noise. We had music playing loudly most of the time and about 30 developers collaborating on different client projects. High vaulted ceilings definitely contributed to noise. It was definitely chaotic, but we managed to remain productive regardless.
At Job 2, my current job (also consulting), we have talked at great length about keeping things quiet and respecting each other's concentration. We have side-rooms if we need to collaborate, and use them frequently. We use chat to ask each other questions rather than tapping on the shoulder (most of the time). I feel extremely productive there (even more so than job 1) and while offices might make tapping on the shoulder even less common, I feel a sense of camaraderie there that I don't think I'd get if I was isolated with a closed door.
Job 3 was by far the worst. It was a similar open space for the entire product team. However, we never had much discussion about communication style or noise, we just always said we don't like being interrupted. Looking back on it, I think productivity was easier at jobs 1 & 2 because we had all agreed on our culture, so we could find ways to work around it. Job 3 was hard because we never knew what to expect. One day it could be quiet and easy to concentrate, but the next it could be noisy and impossible to work in.
The lesson for me is that honesty and openness is most important. If people speak up when they are having a hard time concentrating, then everyone can work together to try to improve the situation. This assumes of course the team respects each other enough to compromise; but if they don't you probably have bigger problems.
Further, who has ever advocated for building desktop apps _without_ a framework? The comparison of client-side frameworks to server-side frameworks is the wrong comparison. If I'm going to build a sufficiently complex Mac app I'm going to use Cocoa, no question. If I just need to automate something and don't necessarily need a UI, I may look at AppleScript or even a simple shell script.
This is more of an apt comparison for web front ends. The choice of Backbone (or, in my case something that provides a little more value like Flight) vs. Ember/Angular is like choosing to build a CLI app vs. a full-on desktop app.
There are perfectly valid reasons for choosing either and in the right context, the right tool is worth its weight in gold.
At an earlier point in my career I was exactly the "highly technical person" in the above comment. I have always taken the approach to my work outlined in the OP, and therefore my emphasis on "getting it right" has caused me to switch jobs quite a bit over the past few years.
For people like me, understanding business constraints is crucial. We must constantly question decisions, not to condescend, but to understand.
Once I understand the context behind a decision, I can then decide if I agree with it or not. If I don't, then I'm in a fight-or-flight situation: try to change it (may not be a reasonable option) or get out as soon as my commitments allow.
Typically once I understand the constraints I start to less like a cog and more like part of a larger effort to ship in spite of our difficulties.
I'm had the same thought Obie. I find high level integration tests provide most of the value for me, with unit testing when I need help with designing code. Having a decent suite of high level tests saves me from having to smoke test the entire app every time I make sweeping changes. If the suite is passing, I know the features are working, at least in the basic cases I was testing for. I still have to do some level of manual testing, but it's nowhere near as much as I did before I became more obsessed with testing.
Interesting... I think I'm with you on this one. There have been a few occasions where I got my test coverage through integration tests rather than unit or functional tests as well.
My real goal is to have tests that will sound the alarm if I've done something that breaks the application. I think this is similar to the "smoke test" you're talking about. Don't want to have to fire up the server and walk through all the use cases - it's very useful to have integration tests that will do this instead.
