In the early days (2013-14?) of Stripe, I was responsible for maintaining my company's integration.
I still remember how one day there was a message on the announcements newsgroup about how the size of a key was increasing, only three or four days before the we'd start seeing the change in API responses. Dealing with this needed a database migration that I would need more time to schedule, and I sent back a polite-but-direct response to the generic posting email expressing my disappointment with how little notice we received.
A couple minutes later a Google Chat bubble pops up from some guy named gdb (aka Greg Brockman), who I subsequently learned was Stripe's CTO. He apologized, asked why the timeline was tough for me, and when I explained it, immediately set something on my account so that the migration would be delayed by a couple weeks.
8 years later I remain impressed by that level of customer connection from a senior executive, and the technical excellence that allowed them to special-case delay my migration.
This is also being done[1] in Canada, in a project that started as a way to use the byproducts of the normal milk-making process in a way that didn't cost farmers anything.
I've had better experiences with DataGrip, but if I wasn't at a place that would pay for proper tools, DBeaver is an OK substitute. Neither, though, have the big thing I want in an analytical SQL workspace:
Simple charts
A whole lot of my work ends up with a three- or four-column table with one column of buckets, and the other being counts of how many things ended up in that bucket. I'd love a view where I could render that into a line or bar chart as a sanity check, and have it update in real-time as I change my query. Instead, I end up having to constantly copy/paste into Excel and do it there.
Yes, I should be using a proper BI or visualization tool for real reports. But sometimes I just need a quick line chart to show that yes, that one count is going in the right direction.
Have a look at Metabase. It's open source, web based and runs from a single JAR. Not the same as a full fledged management tool of course, but I like it for simple queries and charts and the price!
DbVisualizer also has built in charts that are simple but... not free/open source.
>> the campaign should have people in charge of security
OK, but most don't.
Money is a very limited resource in campaigns, and almost all campaign managers will choose to spend it on direct mail and ads over hiring someone for IT security. Their thinking will go "this organization is only around for a year or two, and if we don't win then it won't matter what our IT issues were", and their colleagues in the world of professional campaigning will agree with them. If we're lucky - and I hope we are - the DNC/RNC will have a hotline and national support team for IT security that campaigns can call, but it'll get swamped fast.
Local campaigns don't do enterprise IT. Local campaigns buy G Suite and some old laptops, and leave them sitting around campaign offices in which plenty of not-well-known people come and go. They'll likely be administered by either a contractor hired to set up the offices, or by a friend of one of the early paid employees who "knows computers". While simple changes that individual users can do aren't as through as what you get with a proper security administrator, they're much more likely to get done.
If you're a local[0] campaign and a nation-state actor wants to attack you, they'll probably be successful - but anything you can do to tilt the odds in your favor (like this guide) will help.
[0] Senate campaigns will generally have a small IT team who can do most of the enterprise-level management things mentioned. National campaigns will have a well-staffed IT team to do all this and more.
This is a very good comment. Worth mentioning here is that a typical budget for a Congressional campaign is 500K-1M, while a Senate campaign costs 10M, so can potentially put more resources towards IT.
I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter.
Even with that, though, I haven’t found anything else as good for linking and organizing bugs and tasks, encouraging collaboration between departments and roles, recording discussions and decisions in the place they’re made, interfacing with the other tools we use to run development, and providing a rich SQL-like way to query tickets.
When setting up our JIRA, we made a few decisions to try and make life easier on ICs and hide the bad parts of JIRA:
* Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing.
* Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options.
* Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted.
In the end, some teams used a sophisticated ten-step workflow with granular transitions, and some used it as Trello – but they were all unified in one place, linkable and searchable, and had common support for discussion, auditing, and file management.
I'll add also to periodically figure out what works and doesn't work and why across the company and expand that institutional knowledge to the relevant stakeholders / documentation. Your JIRA flow should provide just a little bit of structure around your existing communication structure.
Remember that you're not a developer anymore, and that the way you contribute to the team isn't coding. You're moving from a role that focuses on concrete contributions, to a role that focuses on creating leverage so that others can contribute better.
Your job now is to manage the state of the projects you're working on, and enable the developers on your teams. If you're coding, you're almost certainly not doing that to the degree you could be. The new job will be difficult. Change is hard, new skills are hard, and there are days you'll want to just go code something because it's easier to do and more fun.
Don't do it.
Your priorities are enabling your team and making sure that everyone knows and is on board with the state of your projects. In your new job, the way you succeed isn't by putting out code - it's by your projects and teams succeeding.
Make sure you like the sound of these priorities; if you don't, you should probably reconsider the change of roles.
Lastly, make sure that you understand what you're accountable and responsible for. Project managers don't (by default) have people responsibility, but at your company they might. Same question about doing product ownership, agile coaching, tactical team leadership, reporting, etc.
If you end up using CloudFormation, don't write the JSON directly. Your programming language of choice should have a wrapper that maps objects to CloudFormation JSON - do your thinking there, use all the features your language offers, and consider the JSON you dump out at the end as an artifact you deploy (which happens to be readable). For Python, this is https://github.com/cloudtools/troposphere - I can't vouch for how accurate other languages' versions are, but I've never had a case where Troposphere didn't generate the right JSON for what I asked it to do.
CloudFormation is also nice in that it has access to a few API features which Terraform doesn't - specifically wait-conditions, automatically rolling-back updates when there's a problem, and a lot of the magic around UpdatePolicy/rolling deploys (although that doesn't work the way one would expect - a story for another day).
Having said that, Troposphere is pleasantly readable and has nice docs. The cross-platform integrations (for example, CloudFlare) add to the "just works" feeling. Some things are a pain to do in Terraform due to its strictness around being declarative and not having conditionals (e.g. having production and development environments that are similar, but not exactly the same), but there are some well-known hacks around them.
It also takes a very strong position around failed updates: it'll stop mid-change, tell you something's broken, and have you fix it. In the same situation, CloudFormation would roll back the changes to the state you were in before you started. Which one of those two failure modes you prefer is up to you. There are also some issues around having passwords and the like in your statefiles when you use RDS. You can avoid this if you go whole-hog into the HashiCorp stack (TF + Vault + Consul + etc.), but it's bugged me.
Lastly, If you're going to build something big and complex in TF, I suggest you do some reading of Charity Majors' rants on TF (https://charity.wtf/tag/terraform/). She has probably already run into the problem you're going to have.
So which would I use? Depends. If I want to create the same environment in a bunch of places (which also includes blue/green deploys), TF. If I want to do more complex things than that, CloudFormation.
We use https://github.com/atward/aws-profile/blob/master/aws-profil... to do pretty much the same thing, although without the $PS1 hacking. Our rule is that a user's default profile should always be the "control account" (on which they have permission to do nothing except STS and AssumeRole), and that they need to use this wrapper and explicitly specify a profile for all "real" API commands. This also works nicely with MFA.
Having this built into TF would be nice, but there are enough tools out there that don't support AWS role-jumping that I suspect we'll end up using that wrapper for a long time.
2-3 months of light work (it was the summer), in Toronto circa 2011.
I had zero professional experience, and bad grades. I knew that for my first job coming out of school, a lot of places would ask for a transcript...so I pointed most of my energy at places where the HR process seemed lax enough that I'd get to talk to developers (who could advocate for me) before I had a conversation where grades would come up.
At the start of my search, the Star/Globe had an insert with "Canada's Top 100 Start-Ups" - I cold-emailed all the ones in there which seemed interesting. A few got back to me, and one of the ones that did is where I'm still working.
As someone on the other side of the table now (at a ~25-dev shop), some things I think about when I'm considering new grads:
* I'm looking at passion, which I use as a proxy for long-term potential upside. You likely won't be a valuable contributor for 6+ months while I get you up to speed on my domain and what real-life professional programming is like. Some new grads can have an immediate impact, but most of those will have already been hired by Google/FB/etc. before they even think of my company. Convince me that you're the one I should be placing my bet on.
* If your CV talks about a mobile app you built, have it installed on your phone so I can play with it. If you talk about a web app, have it bookmarked and walk me though it. If you have one of those you're not excited to show me, I'm going to assume it's bad or you didn't finsih it (so don't mention it). If you don't have one of those and you're a new grad, I'm going to wonder why not. These don't have to be sophisticated; what you're showing me is that you're excited about technology, and can apply it in a non-academic, non-forced context.
* Show that you can communicate well. We're going to be spending a lot of time teaching you stuff, so I'm going to be probing to make sure that you can absorb it all (emotionally and socially).
* Don't focus that much on your specific tech stacks, aside from enumerating them. I'll assume your experience is of limited/academic depth only, and that you don't have much real-world experience. Don't boast that you know Scala when you used it for a project and a co-op term; focus on selling that if I need you to learn OCaml, you'll be a quick study.
Lastly, re: meeting engineers at meetups etc. - don't forget about follow-ups. Maybe the person you had a positive conversation with was just being polite...but it's more likely that they just forgot about the conversation. Send them an email a few days after to remind them you exist.
AWS support has said that ELBs will continue to accept connections (and use the correct backend) for at least an hour after the CNAME stops resolving to a particular IP.
I still remember how one day there was a message on the announcements newsgroup about how the size of a key was increasing, only three or four days before the we'd start seeing the change in API responses. Dealing with this needed a database migration that I would need more time to schedule, and I sent back a polite-but-direct response to the generic posting email expressing my disappointment with how little notice we received.
A couple minutes later a Google Chat bubble pops up from some guy named gdb (aka Greg Brockman), who I subsequently learned was Stripe's CTO. He apologized, asked why the timeline was tough for me, and when I explained it, immediately set something on my account so that the migration would be delayed by a couple weeks.
8 years later I remain impressed by that level of customer connection from a senior executive, and the technical excellence that allowed them to special-case delay my migration.