It's wild to me that they would acquire a company for $295m and then shut it down six years later. I'd be really curious to know if this is a failed acquisition or if they think they'll be able to retain previous ops genie customers on their new products.
Yeah I don't know what Atlassian's strategy was - presumably they were chasing growth and new customers, but I've never worked at a company that has paid for anything more than Jira and Confluence. I'm sure they have a whole list of other services but I've never personally known anyone to use them.
Actually one company I was at did use Stride and it was truly awful - I don't know how its product manager thought it could compete without such basic features as... the ability to edit and delete a message. But some fool at the company I was at chose it because it was cheaper than Slack.
I was using BitBucket for a while, to have paid access to private Mercurial repositories. Once they decided they no longer wanted to support Mercurial, and go with Git, I decided it was best to cut my losses and move to GitHub's paid plans. Atlassian has not handled offboarding of products very well.
First off, it sounds like you’re going through a lot and human to human I want to acknowledge how hard that is. I’d suggest trying to talk to someone to help you heal and overcome the things that you’ve been coping with. When I’ve worked stressful jobs I’ve found exercise to be really helpful. Lastly, just remember that while you need your job economically you’ve already decided to leave, so as much as possible try to not take any of the actions of others personally. If you can put some mental space between your work and yourself it might help you to keep enough energy to focus on a search for something more fulfilling.
There are great teams out there, it does take a lot of work to find them but it is possible to find something fulfilling. Take care of yourself enough during this time so you have the energy to go find something better. I’d encourage you to get started.
It sounds paradoxical, but you need some energy to harness energy. Try to avoid going straight home from work, take a long walk and wear yourself down in an unusual way. Break pattern.
When I was stuck the most career wise, I put my bed in the basement and slept on the couch. Not a recommendation. But you’re allowed to slowly slip out of the life you don’t want.
I work from home... which is it's own set of problems.
One thing I did going through divorce is choose to live somewhere that there are a lot of people around. I have a few restaurants and bars within walking distance... I have found a huge improvement in quality of life just by getting to know some of the bartenders and locals.
Invisible | Remote (EST +/- 6) | Full Time | https://www.invisible.co/technology-careers/ Invisible builds a platform for Operations to run Business Processes. We stand at the intersection of humans and machines building scalable, repeatable processes for business using a combination of automation and humans in the loop. We've built an in house platform that handles the execution of these processes (think Zapier or IFFT that combines automations and human agents) and are solving interesting problems on teams ranging from Infra (Kubernetes, GCP) to UI (Python, Django, Typescript, React, Next.js). We're currently hiring across multiple teams from Junior to Principle level and including Engineering Managers and Directors.
Invisible | Remote (EST +/- 6) | Full Time | https://www.invisible.co/technology-careers/ Invisible builds a platform for Operations to run Business Processes. We stand at the intersection of humans and machines building scalable, repeatable processes for business using a combination of automation and humans in the loop. We've built an in house platform that handles the execution of these processes (think Zapier or IFFT that combines automations and human agents) and are solving interesting problems on teams ranging from Infra (Kubernetes, GCP) to UI (Python, Django, Typescript, React, Next.js). We're currently hiring across multiple teams from Junior to Principle level and including Engineering Managers and Directors.
I applied for the Junior Software Engineer position and passed the take home test and initial interview then just kept getting emails from Bruno saying someone will contact me yet never heard anything. Is there any way you can help me pick up where I left off?
Invisible | Remote (EST +/- 6) | Full Time | https://www.invisible.co/technology-careers/ Invisible builds a platform for Operations to run Business Processes. We stand at the intersection of humans and machines building scalable, repeatable processes for business using a combination of automation and human interaction. We've built an in house platform that handles the execution of these processes (think Zapier or IFFT that combines automations and human agents) and are solving interesting problems on teams ranging from Infra (Kubernetes, GCP) to UI (Python, Django, Typescript, React, Next.js). We're currently hiring across multiple teams from Junior to Principle level and including Engineering Managers and Directors.
Invisible | Remote (GMT +/- 4) | Full Time | https://www.invisible.co/technology-careers/
Invisible builds a platform for Operations to run Business Processes. We stand at the intersection of humans and machines building scalable, repeatable processes for business using a combination of automation and human interaction. We've built an in house platform that handles the execution of these processes (think Zapier or IFFT that combines automations and human agents) and are solving interesting problems on teams ranging from Infra (Kubernetes, GCP) to UI (Python, Django, Typescript, React, Next.js).
We're currently focusing on hiring Principal and Senior level Full Stack and ML engineers, but we are interested in dynamic engineers at any stage in their career.
I joined a project that was fully deployed on Vercel. We routinely ran into issues with limitations, outages and sharp edges. Our junior devs had also taken advantage of Vercel specific features (I remember a Vercel specific request object in the code specifically).
Given all the problems and the vendor lock in from tight coupling I advise everyone I discuss Vercel with to avoid them like the plague.
Invisible | Remote (GMT +/- 4) | Full Time | https://inv.tech/invisible-engineering
Invisible builds a platform for Operations to run Business Processes. We stand at the intersection of humans and machines building scalable, repeatable processes for business using a combination of automation and human interaction. We've built an in house platform that handles the execution of these processes (think Zapier or IFFT that combines automations and human agents) and are solving interesting problems on teams ranging from Infra (Kubernetes, GCP) to UI (Python, Django, Typescript, React, Next.js).
We're currently focusing on hiring Principal and Senior level Full Stack and ML engineers, but we are interested in dynamic engineers at any stage in their career.
I'm currently in the process of removing tRPC from our codebase. It's been a nightmare of tight coupling. I've also found that it encourages more junior developers to not think about interfaces / data access patterns (there's a mapping from Prisma straight through to the component). It's fantastic for rapid prototyping but really paints you into a corner if you ever want to decouple the codebase.
This is the overlooked advantage of a schema (e.g. in GraphQL): it forces you to think about the data types and contract, and serves as a good way to align people working on different parts of the code. It also scales to other languages besides TypeScript which helps if you ever want to migrate your backend to something else or have clients in other languages (e.g. native mobile apps in Swift, Kotlin, etc).
TypeScript is actually a great schema language and fixes a number of problems in GraphQL's SDL, especially the lack of generics.
I think if you're defining a JSON API, that TypeScript is a natural fit since its types line up with with JSON - ie, number is the same in both and if you want something special like an integer with more precision, then you have to model it the same way in your JSON as your TypeScript interfaces (ie, a string or array). This makes TS good even for backends and frontends in other languages. You can also convert TS interfaces to JSON Schema for more interoperability.
It’s not a perfect mapping with JSON. Everyone knows that stuff like functions and dates can’t go over JSON, but there are also subtler things, like the fact that undefined can’t exist as a value in JSON. I’ve seen codebases get pretty mixed up about the semantics of things like properties being optional versus T | undefined.
> Everyone knows that stuff like functions and dates can’t go over JSON, but there are also subtler things, like the fact that undefined can’t exist as a value in JSON
I use `null` for that purpose, and it's been pretty reliable. What are the situations where that falls down?
I also like null | T for required properties, but for whatever reason I have seen that undefined | T is a much more common convention in the TypeScript world. Maybe the reason for that is the semantic about how object access returns undefined, but that’s precisely the source of ambiguity between “object has property X with value undefined” and “object does not have property X”.
TS is a pain with JSON Schema or OpenAPI because it doesn't directly support things like integer or precision. TS does not easily support things like `"exclusiveMinimum": 5`, `"type": "integer"` or patterned (regex) fields.
So if you want to convert your TS interfaces to JSON Schema, you may need to provide additional constraints via JSDoc and use a generator that understands those annotations. But your TS interfaces cannot express those constraints directly.
There are a number other related complications surrounding these more expressive schema definitions - like building types from them and interacting with them at runtime.
Sure, if you have TS in your backend. There are OpenAPI to zod generators that can help get you started, even if they don’t give you perfect zod schemas out the gate.
Jesus, if you're making a JSON API just use JSONSchema, which while not perfect, is quite nice for language interop (and more powerful than typescript)
I'll "just" use the type system built into my programming language until the pain of supporting multiple languages is more expensive than installing JSONSchema tooling and messing with code generation.
We implemented tRPC at work and use all the other things that would have been 'tightly coupled' within our code base had we not planned a tiny bit ahead. tRPC is incredible but it's still just the transport layer between your back-end and your front-end. Allowing the internals of tRPC to be used deep within your business logic is just as bad as not having a clear 'controller' or 'router' layer where you can cleanly define inputs, schemas, and keep things separated. In this sense, if we ever decided to move from tRPC it would be relatively straightforward. Lifting an entire sub-system and running it over a queue for example would be trivial.
Your problem isn’t tRPC, your problem is that you have engineers who type things for typing’s sake. They’ll have the same problem in any tool.
There’s a learning curve to these things. It always starts with type FunctionIWroteTodayArgs = …, which is useless and tells you nothing.
After a few iterations (this takes years) people gradually realize that the goal is to describe your domain and create types/interfaces/apis that are reusable and informative, not just a duplication of your code. You then get more useful types and things start really flying.
I guess what I’m saying is work on that with your team, not on ripping out tRPC.
+1. Almost every time I actually write out a type it's because I want to communicate some domain knowledge. For everything else I use inferred types. IMO this is The Way.
Eh? Useless? Maybe you’ve not written generic Javascript before but “type FunctionIWroteTodayArgs” has eliminated an entire class of problems we used to face with JS code.
If you’re talking about decoupled services, that’s about business domain composition more than type description. And those types benefit from a higher level description/reusability/transportability.
Fair, it’s not literally useless, it does help with typos and autocomplete. But you can get so much more with just 10% extra care in how you design your interfaces that the lazy approach feels almost useless by comparison.
It’s similar to the problems you run into by writing the wrong kind of tests – the ones that essentially just duplicate your code instead of validating input/output at boundaries.
I don't see how declaring an http client server side and consuming it client-side can be a worse thing.
We use the same pattern of creating services that then every consumer can use (a web interface, a cli, etc) and the fact that those things never get to break is a massive improvement over anything I've seen in the past.
If you only ever use Typescript and are sure you’ll never need to interact with the code in any other language or service in a different repo it’s fine. But as soon as you need to reuse that backend for anything else you’re stuck building something new.
You can make calls to tRPC endpoints from anything that can send an HTTP request. The RPC format for requests might not be your cup of tea, but it works.
Ostensibly, the product isn't as useful as the existing gotos (json schemas, shared libraries, graphql, etc), if you cannot create a shareable schema for validation. The ability to form arbitrary requests is already assumed. If your messages are very complex, you need some tooling.
Having the opposite experience with it as a small team, and I can see how it would work great in my past large teams. I bet you're gonna have the same complaints about any API you use not just tRPC (junior developers not thinking about interfaces).
I’m willing to admit that poor usage can make any tool a problem. But, tRPC is set up to make it easy to directly expose your backend for use in a component. For new projects that’s fantastic, for larger projects and teams having the ‘friction’ of defining a gRPC, GraphQL or REST endpoint is leading to more thoughtful API design and ability to keep isolation between layers.
It's a dangerous anti-pattern to pass your db types through to your api handlers. Those are always different models and it's important to have an intermediary representation for the rest of your domain.
Agreed. Although, sometimes it feels like this is a losing battle. I've worked with too many people who see that level of separation as "unneeded duplication", with constant complaints about having to update a bunch of different layers "just to add a new field.
IMO, at a minimum, you have your API layer model, your internal model, and your database model with a mapping layer at each boundary.
I rarely have problems when I structure it that way, but when working on applications that pass the same model from their API down to their database, or vice-versa, it's always full of the same types of problems that comes with tight coupling.
I think there are certain types of boilerplate that used to be truly onerous that are now much less so because of types. If there are 3 different files that need to be updated to add a file, and forgetting one is only going to error at runtime (maybe even only if you're exercising that new field) that's horrible. But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem.
> But 3 files that require updating where the code won't compile until you've added all three is way way less of a problem.
I think this is only really possible in a relatively small subset of programming languages, even among those with static typing. At a minimum it seems like it would require a type system that didn't allow optional properties (by default) and did distinguish between nullable and non-nullable types.
Unless I'm missing something. Would love to see some examples of this done right. Or at least examples of languages you've done this in.
The company that I work at does exactly the service that you're describing. We recently spun up a team of Math PhDs to help with data labeling. (https://www.invisible.co/). We're seeing more and more of our clients ask for graduate level data labelers and content creators.
