XVincentX

  Location: Denver, CO
  Remote: Yes
  Willing to relocate: Yes
  Résumé/CV: https://linkedin.com/in/vncz
  Email: [email protected]

API architect with 15+ years transforming how organizations design, build, and scale developer platforms.

At Microsoft, architected Graph APIs serving 100M+ users and established design standards for 200+ engineering teams. Previously led platform engineering at Stoplight and SentinelOne, specializing in OpenAPI tooling, developer experience, and building internal APIs that enable product teams to ship faster with confidence.

  Location: Denver, CO
  Remote: Yes
  Willing to relocate: Yes
  Technologies: Clojure, Python, TypeScript, Cloud Stuff
  Résumé/CV: https://linkedin.com/in/vncz
  Email: [email protected]

Over the last 10 years I have worked for companies in the developer productivity space, in particular in the API Design space.

Currently I am working for Microsoft as an API Architect for Microsoft Graph where I help with the design of APIs very likely you have used, and curate the internal developer experience.

I might be a very good fit for you if

- You are looking for somebody with encyclopedic experience in software development

- You need somebody to dig into a codebase in a bad state and bring it back to excellence

- You need somebody to improve the developer experience of your users, whether they are internal or external

- You need somebody with very strong API Design Skills

- You need somebody that is very well versed in Cloud Environments such as AWS/Azure/GCloud

> The last 12 months have been an incredibly frustrating time for Windows fans.

Windows fans? What?

Location: Denver, Colorado

Remote: Yes, or hybrid

Willing to relocate: Depending on which target state, YES

Technologies: Clojure, TypeScript

Résumé/CV: https://www.linkedin.com/in/vncz/

Email: [email protected]

For the last 10 years I have been working primarily for companies building tools for developers involved with large HTTP APIs (Apiary, Stoplight to name a few). Some of the open source tools you currently use when dealing with OpenAPI might have been written by me.

Currently I work as API Architect where I help design and ship big APIs, work in internal tools and help with the giant API Gateway that serves billions of requests per day and coordinates the various services for ${bit-company}

I can help in architecting very big systems, on the cloud or not, building tools for internal and external developer productivity and I am particularly good when thrown in codebases with a lot of technical debt and bring them back on a path to excellence.

Who wants to be hired

  Location: Denver, Colorado
  Remote: Yes, or hybrid
  Willing to relocate: Depending on which target state, YES
  Technologies: Clojure, TypeScript
  Résumé/CV: https://www.linkedin.com/in/vncz/
  Email: [email protected]

For the last 10 years I have been working primarily for companies building tools for developers involved with large HTTP APIs (Apiary, Stoplight to name a few). Some of the open source tools you currently use when dealing with OpenAPI might have been written by me.

Currently I work as API Architect where I help design and ship big APIs, work in internal tools and help with the giant API Gateway that serves billions of requests per day and coordinates the various services for ${bit-company}

I can help in architecting very big systems, on the cloud or not, building tools for internal and external developer productivity and I am particularly good when thrown in codebases with a lot of technical debt and bring them back on a path to excellence.

  Location: Denver, Colorado
  Remote: Yes, or hybrid
  Willing to relocate: Depending on which target state, YES
  Technologies: Clojure, TypeScript
  Résumé/CV: https://www.linkedin.com/in/vncz/
  Email: [email protected]

For the last 10 years I have been working primarily for companies building tools for developers involved with large HTTP APIs (Apiary, Stoplight to name a few). Some of the open source tools you currently use when dealing with OpenAPI might have been written by me.

Currently I work as API Architect where I help design and ship big APIs, work in internal tools and help with the giant API Gateway that serves billions of requests per day and coordinates the various services for ${bit-company}

I can help in architecting very big systems, on the cloud or not, building tools for internal and external developer productivity and I am particularly good when thrown in codebases with a lot of technical debt and bring them back on a path to excellence.

  Location: Denver, Colorado
  Remote: Yes, or hybrid
  Willing to relocate: Depending on which US state, YES
  Technologies: Clojure, TypeScript
  Résumé/CV: https://www.linkedin.com/in/vncz/
  Email: [email protected]

For the last 10 years I have been working primarily for companies building tools for developers involved with large HTTP APIs (Apiary, Stoplight to name a few). Some of the open source tools you currently use when dealing with OpenAPI might have been written by me.

Currently I work as API Architect where I help design and ship big APIs, work in internal tools and help with the giant API Gateway that serves billions of requests per day and coordinates the various services for ${big-company}

I can help in architecting very big systems, on the cloud or not, building tools for internal and external developer productivity and I am particularly good when thrown in codebases with a lot of technical debt and bring them back on a path to excellence.

The question for me is whether this is a Microsoft only problem - or an hidden problem for all these “AI” companies

The article is wrong. Rich Hickey is talking about the surface of the function, interface. The implementation details do not matter in this case.

Reminds me a lot what Thomas Sowell says in Charter School and Their Enemies book

They can up to a certain point. MSFT Defender logs has some info with regards what has been deleted, but some other information are missing (such as command line parameters associated with the lnk file)

Swagger (OpenAPI 2) and OpenAPI 3 never supported JSON Schema. They support a subset of the draft 4 with custom additions. OpenAPI 3.1 added support for additional schemas where you can use whichever draft you want.

Disclaimer: I work for Microsoft as an API Architect.

I am not working on this specific API, so I am not going to comment on anyway. I hear your complains about Microsoft API guidelines (which is an entire different conversation) but I wanted to add my two cents with regards to JSON Schema.

The problem that I have been having with JSON Schema since forever - is that the data that is being modeled is complected with contextuality of its usage. For instance, if I have

type user = { name: string, surname: string, password: string }

IN JSON Schema it is very hard to give contextuality on it, and most of the times involves having two separate types.

Here is an example:

If I am creating a new user, then name, surname are mandatory, while password is not because the system is autogenerating it. If I a logging in - then I want ALL of the fields.

As of today, it is very hard in JSON Schema to express this.

Basically speaking, I am arguing that the data structure is a thing, another one is its usage in a context, where there can be requirements and complicated validation logic involving even other fields

In my experience, the only thing that has been very very close to what I have been looking for when modelling systems is Clojure. Most of the people laugh to my face when I say that primarily because it is a LISP 2 and yet... In particular, spec (and even better spec2) have the tooling to express data structure as sophisticated as we want without a type system and with the contextuality constraints that are fundamental for a real type reuse.

I used to hate the JVM, Clojure changed my mind so much. I am glad I found it.

Clojure is a very good success story of a functional LISP running on the JVM.

On the same topic: When An Error Is Not An exception Series: https://dev.to/vncz/series/6223

SentinelOne | Backend Developers | Remote (US) | Full-Time | https://sentinelone.com

After the successful launch of the new Singularity Marketplace, I am looking for an engineer to join our small Apps engineering team in the United States. We want somebody that has been in the trenches working with medium/big systems, loves functional programming (even if is afraid to say that loudly) and has a solid API background.

You’ll be working with a variety of partners and their APIs to supercharge SentinelOne’s threat analysis and detonation. Sometimes we’ll be dealing with nice OpenAPI files, semantic status codes and structured error responses; sometimes the documentation is an email, every API call returns 200 (even if an entire server farm has just crashed) and payloads are so nested that you’ll need a GPS to figure out where you are. Are you up for the challenge?

If you:

* Have experience with functional programming languages (Clojure, Haskell) or strong desire to learn

* Have experience with Node and TypeScript or strong desire to learn

* Have experience in designing and implementing (real) RESTful APIs

* Have used and survived other people’s API

…and you’re interested in

* Designing and implementing public APIs for external users

* Build and maintain user SDKs in different languages

Then please email me at vncz at SentinelOne.com and let's chat.

SentinelOne | Backend Developers | Remote (US) | Full-Time | https://sentinelone.com

After the successful launch of the new Singularity Marketplace, I am looking for an engineer to join our small Apps engineering team in the United States. We want somebody that has been in the trenches working with medium/big systems, loves functional programming (even if is afraid to say that loudly) and has a solid API background.

You’ll be working with a variety of partners and their APIs to supercharge SentinelOne’s threat analysis and detonation. Sometimes we’ll be dealing with nice OpenAPI files, semantic status codes and structured error responses; sometimes the documentation is an email, every API call returns 200 (even if an entire server farm has just crashed) and payloads are so nested that you’ll need a GPS to figure out where you are. Are you up for the challenge?

If you:

* Have experience with functional programming languages (Clojure, Haskell) or strong desire to learn

* Have experience with Node and TypeScript or strong desire to learn

* Have experience in designing and implementing (real) RESTful APIs

* Have used and survived other people’s API

…and you’re interested in

* Designing and implementing public APIs for external users

* Build and maintain user SDKs in different languages

Then please email me at vncz at SentinelOne.com and let's chat.

  Location: Austin, TX
  Remote: Yes
  Willing to relocate: Yes
  Technologies: TypeScript, Clojure
  Résumé/CV: https://linkedin.com/in/vncz
  WebSite: https://vncz.codes
  Email: hey {at} vncz {dot} codes

Or, better:

  (def vncz {:location "Austin, TX"
             :remote true
             :relocate true
             :tech #{:typescript :clojure}
             :resume "https://linkedin.com/in/vncz"
             :website "https://vncz.codes"
             :email "hey {at} vncz {dot} codes"})

Over the last 6 years, I've been mostly working for SAAS companies providing tools for API Developers, contributing heavily on the engineering side as well as managing small teams.

I help organise the APIDays (https://apidays.co) conference series.

I'm a Google Developer Expert, Auth0 Ambassador and a Microsoft MVP in Developer Technologies.

I infrequently write what I learn during my work at https://dev.to/vncz

I'm looking for a lead/principal developer position. If Clojure even better, but TypeScript would do the job also.

I'm not an expert in databases, but I am starting to think that building an interface primarily designed for humans (that's what SQL is) as the main medium to interact with the database maybe in retrospective was not a winning idea.

I'm not criticising anybody here (I am literally not in a position of critiquing anything); SQL was created probably 40 years ago and it probably made sense back in the times.

My point is that you can always build a human interface from a machine one; the reverse is not that easy. ORMs are a (failed?) attempt to do so.

I would very much push for computer-language integrated query support — (such as Datalog or Linq), and that is what the database server should be accepting as input, instead of a raw string.

Although a lot of people hate MongoDB, I've personally felt way more productive expressing queries with their query document system rather than using SQL.

Fixing design flaws with other software ain't gonna bring us that far maybe.

  Location: Austin, TX
  Remote: Yes
  Willing to relocate: Yes
  Technologies: TypeScript, Clojure
  Résumé/CV: https://linkedin.com/in/vncz
  WebSite: https://vncz.codes
  Email: hey {at} vncz {dot} codes

Or even better…

  (def vncz {:location "Austin, TX"
             :remote true
             :relocate true
             :tech #{:typescript :clojure}
             :resume "https://linkedin.com/in/vncz"
             :website "https://vncz.codes"
             :email "hey {at} vncz {dot} codes"})

Over the last 6 years, I've been mostly working for SAAS companies providing tools for API Developers, contributing heavily on the engineering side as well as managing small teams.

I infrequently write what I learn during my work at https://dev.to/vncz

I'm looking for a lead/principal developer position. If you're working in Clojure even better, but TypeScript would do the job also.

I'd love to see them out of the language. I do not have evidence/document supporting this, but I think it was ultimately a failed attempt of copying the C# feature ignoring the fact that JavaScript works differently.

Correct, but that does not solve the other issues I pointed.

Additionally, const enums DO NOT have an associated type. That is a problem in libraries, since users cannot reuse the type definition around (it back ports to a string or a number)