I believe using `defaultValue` instead of `value` would be an appropriate remediation.
767 karma · joined February 5, 2010
Contact:
https://angel.co/cyranix (AngelList)
http://cyranix.github.io (profile, currently outdated)
Location:
Seattle, WA
Currently:
CTO at Hazel Analytics (Seattle, wA)
Selected history:
Developer at Socrata (Seattle, WA)
Developer at Moveline (Las Vegas, NV)
Developer at MyEdu (Austin, TX)
Rice University (Houston, TX), B.A. in linguisticsIf you think about projects that way, a few of my recommendations are:
0) Set up clear organizational guidance for project artifacts. Where will all of the docs and spreadsheets go? How will you keep track of which issues are relevant in your issue tracker? How can stakeholders get self-service updates on the project? Keep labels and naming as consistent as possible across the various services you use. For more formal situations, you might also need to set up RACI or similar communication structures.
1) Define measurable outcomes as success criteria from the very start. Do you want to increase customer lifetime value, or get more daily active users, or decrease AWS spend, or...? You need at least one, and probably no more than five if you want to stay sane, and they all need a target number. Measure your starting number, and document how you calculated it, because you're going to need to use the same method again later. (It really helps if at least one of your measurable outcomes has a non-zero starting point.)
2) Conduct a pre-mortem. Everyone on the project (or representatives of each role, if somehow your team is too big) gets together and imagines that the project is complete but ended up going less-than-well. Brainstorm every failure mode you can think of, then brainstorm ways to prevent or mitigate each failure mode. Some failure modes are unavoidable, and it's good to recognize that too. Create tasks to follow up on each preventative measure.
3) Set milestones to gauge progress. This can be lightweight and still be useful. Each milestone allows you to evaluate the impact of unforeseen challenges, whether the quality of work is high enough, whether scope or time needs to be adjusted, and even whether to pull the plug early. Iteration boundaries are fine milestones.
4) Conduct a retrospective when the project is complete and enough time has passed to collect the appropriate metrics. Check the outcomes using the calculations from step 1. Celebrate successes, assess shortcomings, and brainstorm ways to improve the way that projects are run. It's surprisingly important to be explicit about learning from past mistakes. Now you're ready to rinse and repeat.
These principles are orthogonal to, or perhaps operating on a higher level than, kanban or agile or what-have-you. None of the above ideas force you into a waterfall methodology, but they may require you to think a bit harder up front. It's also not incompatible with continuous deployment or other similar development practices.
Not disagreeing with the idea that there aren't a variety of reforms that seem mutually beneficial, such as shorter timeframes — just noting that there are not equivalent to NDAs.
http://thisiscriminal.com/episode-68-all-the-time-in-the-wor...
(But please, just do me a small favor and don't submit any reports for SQL injection or information disclosure if you're using the SQL-like API that we expressly provide for the purpose of accessing public data. We get a couple clueless people sending such reports every week.)
I'm sure The Stranger will have a field day if anyone actually gets kicked off because of this "don't share with the media" position. And if NextDoor think that media folks aren't already embedded, in every neighborhood group, so they can have access to the kinda-racist goings-on of the platform, they are surely mistaken!
Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).
I would expect that Increment will run less risk of burning through many important topics quickly and having their later issues tread the same ground, just shallower. We already have plenty of venues to get news about bleeding-edge developments in the tech world — HN, for instance! I wouldn't be upset if the topic of on-call weren't covered in Increment for another 2-3 years, so that the content can be more substantive and battle-tested.
Kudos and thank you, Stripe!
Externalizing a process that previously existed only in someone's head is a win. Creating a checklist is a straightforward framework for such externalizing, and allows you to separate the question "how do I accomplish my goal?" from the question "how do I express this with code?" (like writing pseudocode before real code).
Whether a process is automated or manual, there's always room for error if the surrounding context changes. When an automated process is annotated _like_ a checklist, I find that I get the best of both worlds: minimal affordance for human error with a clearly described thought process to fall back on in the event of a problem.
(It's also not terribly uncommon to have steps that can't be fully automated, like authenticating to a VPN with 2FA under certain security frameworks...!)
First I was hired for a mid-level mostly-remote web dev position at Moveline and stayed there roughly a year until the company folded.
My current job at Socrata, where I've been quite happy for the past 18 months, also came via a monthly HN jobs thread; it has been mostly doing frontend web dev (but with enough variety).
If I find myself in need of employment again, I will undoubtedly turn to the jobs thread again.
Discovering the patterns within the apparent randomness (without the aid of wikis, for the most part) was a big part of the game's appeal to me. Depending on what kind of randomness I'm facing, I might need to make quick decisions about timing or routing or resource usage, often needing to weigh risk vs. reward along several dimensions at once. This game does so much with so little, and the attention to detail and thoughtful design have always shone through for me, all along my journey from bewildered novice to cunning whiz.
With a huge back catalog of video games in existence, it says a lot that one can look forward to returning to a timeless classic like Spelunky.
Please resist commenting about being downvoted.
It never does any good, and it makes boring reading.
Please don't bait other users by inviting them to downvote
you or announce that you expect to get downvoted.Socrata builds cloud-based software that democratizes access to public sector data, enabling individuals, businesses, and governments to understand their communities more clearly and make better decisions. Our products power open data portals for many major cities, states, and federal agencies [0, 1]. Much of our work is released as open source [2, 3] and we enjoy engaging with the broader community through Open Seattle [4].
We’re looking for strong engineers across a variety of teams. DevOps engineers are working on our Mesosphere/AWS/Chef runtime platform. Front-end engineers work primarily in Rails and Angular, with a gradual introduction of React underway. Back-end engineers tend to write Scala or Java, though there are other languages in the mix as well (notably Python for some of our machine-learning projects).
To learn more about our company culture and apply for positions, check out http://careers.socrata.com.
(On a personal note: I've been with Socrata for eight months and I'm thoroughly impressed with the engineering culture. We've got a talented, dedicated, and pleasant team here, with strong communication/collaboration skills and a genuine interest in the company's mission.)
[0] https://www.socrata.com/customer-stories/
[1] https://www.socrata.com/case-studies/
[2] https://github.com/socrata/
On the rare occasions when I play a game of pool, a little piece of my brain remembers the pool-table section from this video as I try to make bank shots.
The information is coming from publicly available descriptions of vulnerabilities. The affected versions of gems are already enumerated. This tool is a way to make it easier for devs to compare their set of gems against the vast database of vulnerabilities.
I was a developer at Moveline (which shuttered, sadly, this past December). Around the start of 2014, the company adopted holacracy as its organizational model; while there were certainly other valid reasons to do so, but I know that it was in part motivated by the fact that another Las Vegas-based company, Zappos, was also an adherent. Over the course of the year, in addition to writing code, I also served as the elected secretary for the dev team and facilitator of the GCC (General Company Circle; top-most level of the hierarchy), attended holacracy training courses, and coached people throughout the company about the mechanics of holacracy and how to make it work for them. Suffice it to say, I was pretty immersed, so I feel like I can represent how things played out at Moveline fairly accurately.
The up-front costs associated with shifting from a traditional structure to any other structure can be pretty massive; holacracy is no exception to that rule. Bigwigs from the official holacracy company (HolacracyOne) came onsite to give talks and run the first several meetings, which cost a decent chunk of change as well as taking time out of a busy startup's day. Teams and roles needed to be defined using the terminology and mechanics of holacracy. There were impacts here and there to scheduling, to communication systems, and to getting things done in general. Eventually, however, the ramp-up phase ended and we were able to experience holacracy in full.
As you might expect, there were established figures in the company who felt strong resistance to holacracy. Some of them held significant managerial power before the transition; others wanted a flatter, less formal approach. Those tensions came up fairly frequently in meetings and other conversations, and it created an atmosphere of not being quite satisfied with how things were being run (not that these people should have stifled their opinions, mind you). This problem was compounded when we entered a major growth phase, going from under 40 employees to over 100 in the span of a few months. New hires were unfamiliar with holacracy, necessitating additional training, but just as importantly they entered an environment where low-grade dissatisfaction with holacracy was palpable. If there's a lesson here, it's that adopting holacracy requires far more buy-in than you might expect. (For what it's worth, I'm not aware that anyone ever felt unable to voice their dissatisfaction at Moveline; we had a culture of open and honest talk, but identifying an issue isn't the same as solving it.)
A natural question to ask at this point is "What about backing out of holacracy?", to which I'd reply that it's easier said than done. Since a not-insignificant amount of effort goes into the initial setup, it's easy to fall prey to the sunk cost fallacy. The rationalization is reinforced by HolacracyOne, who clearly stated to us that most companies won't really be fully operational as holacratic organizations for at least six months. Actually, the tenets of holacracy itself reinforce the idea that you just have to keep pushing forward no matter how weird it may feel: the first setup step effectively tears down a bunch of preconceptions about corporate structure, and you won't really feel like you've gotten to the point where you can critique holacracy until you rebuild that structure.
The flexibility you get for achieving the new structure is touted as a feature, but the less marketable truth is that it's a double-edged sword. Holacracy is purposefully vague on where the authority for hiring, firing, and budgets will live. Lead Links aren't managers, but they are accountable for resource allocation that isn't defined elsewhere — and it's up to your company to figure out what limits are placed, who places the limits and how, what constitutes a "resource", and so forth. It's entirely possible for an employee to have zero roles — and it's up to your company to figure out whether that has any correlation to terminating employment, changing teams, hiring needs, and so forth. Furthermore, self-defining teams present an unfortunate opportunity for organizational thrashing; at Moveline, we saw major revisions to the structure around meta-org work (HR, facilities, finance, etc.) and our sales/support teams every few months. Those upheavals, while well-intentioned, degraded individual performance, disrupted internal communication, and fed back into the underlying dissatisfaction.
I haven't read The Tyranny of Structurelessness cited in many other comments, but from the title alone I am assuming that it's an accurate depiction.
That said, there is one thing that I feel like holacracy helped with significantly: the emphasis on well-defined decision-making. When teams stopped saying "We will get this done" and started routing tasks to specific individuals (who had an obligation to perform those tasks according to the roles they held), it was clear that the reduced ambiguity had a positive impact. The use of "we" has its place in an organization, of course, but "we" is just a code word for "not sure who" when it comes to planning specific, concrete work that needs to get done. If you're not careful, things can get a bit political when it comes to defining authority (at Moveline, this often related to holacratic "domains"), but I'd still consider the technique of specific task attribution as something I'd want to bring to future workplaces.
I'm happy to answer any other questions about my views on holacracy that HNers might have.
Remote: Preferred
Willing to relocate: Yes
Technologies: JavaScript (Node, jQuery, Angular, learning React); Java; PHP; various databases (most recently PostgreSQL and MongoDB); plus experimentation or quick hacks in other languages
Résumé: http://cyranix.github.io
Email: andrew.m.harrison+hn@gmail.com
I am most interested in organizations with opportunities in a social-good space such as education, health, the environment, justice, or civic engagement. In addition to my coding skills, I also have exceptional communication skills and enjoy opportunities for leadership and mentorship.
Sports as a team activity, a friendly space to be physically active and competitive (with varying degrees of physical injury risk depending on the sport), are fantastic. I was a three-sport athlete in high school and consider the lessons learned in that context just as important as some of the coursework. My cross-country team was full of AP math and science kids, while my soccer team had more of the kids who smoked pot and goofed off in class. Even supporting the teams I didn't belong to meant finding common ground with those I might otherwise have never associated with.
When I consider the professional sports phenomenon, I can't suppress my knowledge of its more insidious aspects. The ludicrous salaries in an age when the disparity between rich and poor is becoming more painfully exacerbated, and the effect that this allure has on the American educational system. The reinforcement of racially motivated prejudices. The disregard for players' physical and emotional well-being, as well as other more casual disgraces that Marshawn Lynch could readily identify. The vitriol frequently associated with team fandom (which I am fortunate to have escaped despite growing up in the heart of the SEC).
I don't begrudge anyone their enjoyment of collegiate or professional sports. Once in a blue moon I'll even attend a football or hockey game at a friend's invitation, and I whoop and cheer and critique just like the next guy. But don't ask me to fall in line with the majority and unreservedly celebrate professional sports just so I can "identify with the common man". I don't watch the Super Bowl, despite invitations, not because I feel some elitist need to prove my refinement to others, but because it's difficult for me to support a system that contradicts my values on so many counts.