JBerlinsky's comments

Barefoot Coders | Technical Sales Director | REMOTE | Full- or Part-Time | https://www.barefootcoders.com

Barefoot Coders is a software and technical infrastructure development studio, helping companies of all shapes and sizes thrive in the cloud-native landscape. We operate a successful professional services business, and are looking to scale our operation by bringing on a talented Sales Director to help identify opportunities, scope them, and manage the account lifecycle.

We're a small team, and we're going to define this role together. We're keeping the definition loose because we care more about ability and fit than who's already in your rolodex. We're looking for smart people who get things done, aren't afraid to jump into challenging problems, and can adapt quickly to the ever-changing technology landscape.

If this sounds interesting, shoot me an email: [email protected]. If it's not for you, but you refer the right person, we pay a $1,000 referral bonus.

Barefoot Coders | Technical Sales Director | REMOTE | Full- or Part-Time | https://www.barefootcoders.com

Barefoot Coders is a software and technical infrastructure development studio, helping companies of all shapes and sizes thrive in the cloud-native landscape. We operate a successful professional services business, and are looking to scale our operation by bringing on a talented Sales Director to help identify opportunities, scope them, and manage the account lifecycle.

We're a small team, and we're going to define this role together. We're keeping the definition loose because we care more about ability and fit than who's already in your rolodex. We're looking for smart people who get things done, aren't afraid to jump into challenging problems, and can adapt quickly to the ever-changing technology landscape.

If this sounds interesting, shoot me an email: [email protected]. If it's not for you, but you refer the right person, we pay a $1,000 referral bonus.

Each state has different laws about how people need to be notified about data breaches. U.S. mail is generally the lowest common denominator across states. See https://info.digitalguardian.com/rs/768-OQW-145/images/the-d... for more information if you're curious.

Existing discussion here: https://news.ycombinator.com/item?id=20990583

You might want to look into Terraform [1], which works across multiple cloud vendors, with pluggable open-source "providers" facilitating the communication with the backend cloud platform.

[1]: https://www.terraform.io/

Yes, developers can request permission to access your inbox "offline" (i.e. at any time, with a long-term access token). The scope is clearly identified in the OAuth authentication process, and the consent screen clearly asks for permission to (IIRC) "read, write, and delete emails." There are a few well-known applications (Earny and Unroll.me come to mind, off the top of my head) that are known to work with consumer research operations with the resulting data.

Google does indeed have an office in Ann Arbor. As far as I remember, it's quite light on engineers, though; I'd be surprised if any seniors are there.

https://www.informationweek.com/database/the-man-who-torture..., perhaps?

I'm a consultancy owner where our engagement mode slightly resembles a freelancer model. There are a few things you should keep in mind (some of which have already been mentioned in this thread):

1. Don't participate in the race to the bottom on price. The goal with most MVPs, in my experience, is to build something that can feasibly be expanded beyond the MVP point. If you work with someone inexpensive, you're likely to wind up with something that, even if it meets your goals, will be difficult to expand upon beyond the initial scope. Of note, you should bear in mind your growth plan beyond the MVP. For example, do you want this freelancer to stick around long enough to help install an internal team? If so, you almost certainly want someone with management/hiring experience, not necessarily a recent code bootcamp grad.

2. Don't work with someone on a fixed-fee if your business has any possibility of adjustment. There are plenty of shops and freelancers out there who grossly misunderstand what it means to be "agile." Agile software development isn't just about the tools and processes one uses to build software -- it's about alignment with the business at any given point in time, and an engineering team's ability to adjust as your business realities change. For example, as you're building your MVP, if you discover that feature X is critical to a large customer using your product, you're logically going to want to introduce it to your MVP scope and prioritize it accordingly. Working with someone on a fixed fee incentivizes scope-freezes when the work is started, which might have financial advantage for you in the short term, but can greatly hinder your ability to adjust as the world changes around you and your business.

3. Work with people who are aligned with your business. Someone who isn't willing to understand the actual business machinations at play behind your MVP is not going to be understanding of your priorities, and won't be able to make informed technical recommendations. You might not think you're looking for a CTO-like figure or anything of that ilk, but when first building out a MVP that you hope to grow beyond that, this level of insight is extremely valuable.

3a. When working with consultancies in particular, do not try to offset monetary payment with stock/equity. It's a clear red flag for us.

4. Work with people you can trust. If you don't have someone in your network, go out of your way to build that trust.

5. Have an idea of what you want, but be willing to listen. Some of us have done user research a million times and know what people don't want to see in a product, and the good ones are going to bring such things to your attention. You know your business better than outside people/organizations, but they might know something you don't.

I'm happy to have a conversation about this with anyone interested. Email in profile.

Barefoot Coders | DevOps Engineer - Google Cloud and Terraform | New York, NY | FULL-TIME, REMOTE

We've partnered with a cloud services provider to help migrate global enterprises into the digital era. We're looking for a collaborative DevOps Engineer, comfortable with Terraform and Google Cloud Platform. You'll be working closely with our Director of DevOps alongside our client team. This is a highly collaborative project where your expertise will be valued deeply. We're looking for someone who is comfortable with periodic client-site visits.

You are an experienced engineer with a wide range of engineering skills. You delight in building reliable, resilient systems that help businesses grow and mature their technical offerings. You are collaborative, and enjoy working with teams and clients to make sure that the right thing gets built at the right time.

Not the right person for the job? That's ok! If we wind up working with a candidate who mentions you sent them this link, we'll pay you $1,000.

Apply here: http://bit.ly/barefootcoders-devops-gcp-terraform

We've used Nextravel[0] for this. It's a great compromise between running travel in-house and solutions designed for larger companies like Concur.

0: https://www.nextravel.com/

It's all about your network and supply/demand. Be picky with your projects, and leverage them into your next contract.

On that note, if you happen to have immediate-ish availability, shoot me a message (email in profile).

My pleasure! At the end of the day, whatever works best for your workflow is ideal, of course.

You might also want to look into https://github.com/runatlantis/atlantis, which provides the benefits of Terraform Enterprise, in an open-source, self-hosted format.

To your points:

>> - Speed up development time by doing test locally - don't need to commit and wait a build kick it and see whats wrong

Combined with the article linked, it sounds like you're working in an environment where the only machine authorized to interact with AWS, or retain the Terraform statefile, is a Jenkins build server. Might I suggest investigating Terraform Enterprise (despite the name, it's rather affordable, for what you're getting)? TFE integrates with Github (and other VCS) pull requests, allowing a pull request to trigger a `terraform plan`. This gives a pretty good understanding of whether your changes are going to succeed or not, and are pretty quick to run -- I work on some rather large projects, and have never waited more than a few minutes for a plan to complete.

If you're allowed to pull down the statefile, you can also just run `terraform state pull > terraform.tfstate && terraform plan`.

>> - Able to be part of the bigger scheme where you can test your whole "infrastructure" or part of it at least we still limited by localstack.

In my experience, mocking systems like `localstack` are never quite up to the "standard" of the systems they intend to mock (AWS in this case). Of particular note, AWS's APIs, especially for newer products, tend to have lots of "gotchas" that are undocumented or hard to trace back -- things that are extremely unlikely to be covered well in a mocking framework.

If this works well for you, great! Just giving my two cents, as someone who has thought a lot about this and wound up right back at `terraform plan`.

I'm not sure I follow the use case here. Perhaps it's just a function of my use cases for Terraform.

Terraform comes with `terraform plan`, which does a cursory validation of the infrastructure-as-code, diffs it against the current state of the world in various accounts, and reports back with what it expects to execute. While there are some cases where `terraform plan` succeeds and `terraform apply` errors, they tend to be cases that I don't think mocking would catch. For example:

- Certain AWS resource naming restrictions are not handled by `terraform plan`, but are caught by the AWS API, causing `terraform apply` to fail.

- The validity of AWS ACM certificates (issued vs pending) is not handled by `terraform plan` -- `plan` assumes that any certificate ARN provided is valid and issued, whereas the AWS API will error if the certificate is not valid, prompting `terraform apply` to fail.

There are plenty more examples (duplicate security group rules come to mind as a particularly egregious offender). I'm just not sure I see what value this provides -- if I'm missing something, please do let me know!

There are plenty of organizations that are incorporated as Public-Benefit Organizations that might still be considered objectionable to get a free pass on hiring posts.

I generally love Let's Encrypt and what they stand for, but the subjective measure of "public good" is a dangerously slippery slope.

If you're in NYC, I know a few people who might be able to help you out; shoot me an email (in profile).

Shoot me an email (in profile) if you'd like some domain expertise :)