Location: Denver, CO
Remote: Yes
Willing to relocate: Yes
Résumé/CV: https://linkedin.com/in/vncz
Email: vnczes@icloud.com
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: vnczes@icloud.com
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
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: vnczes@icloud.com
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: vnczes@icloud.com
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: vnczes@icloud.com
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 article is claiming that the surface and the implementation are related.
If client code passed a null value before, an error would have occurred. Now it is handled with a default that the original code was not accounting for, and this might be bad.
Thus the change in interface _is_ a change in behavior.
Old situation: called function says: "i would crash if you gave me a null value, so my interface says you cannot give me a null value"
New situation: called function says: "i no longer crash if given a null value, which you couldn't do before anyway, so you won't notice any difference"
But they could pass null, though. Clojure doesn't stop you from passing null anywhere.
Also, thrown exceptions are values. Consider for example a function that searches for a file a return null if it's not found, which you are composing with a function that opens a file but throws on null. You might very well write something like open(search(...)) and catching exceptions above that level. Now if I make open(..) able to accept null (maybe it opens a temp file?) then you now need to add a null check on the return value of search to get the old behaviour. That is 100% a breaking change!
> Clojure doesn't stop you from passing null anywhere
As a C++ programmer (oh, the horror!) I'd say that's an issue with Clojure rather than the general principle. And also one of the reasons I like the pointer/reference distinction in C++ (the former allows null values, the latter does not).
But sure, that changes my interpretation somewhat. It doesn't really change program safety, however.
But you already had to have a null check on on the return value of search if open wasn't previously able to take null, so the behaviour of your code hasn't changed.
If the code passed in a null value before, it was violating the contract the function provided. A component isn't responsible for what happens when you operate it out of spec.
If I were a hardware designer and some changes to an IC I'm working on are going to make the next batch, say, work properly in hotter temperatures than it could before, and one of my coworkers comes and says, "Don't make that change, what if someone using that IC is deliberately operating it out of spec expecting it to fail and now the behaviour is going to change!" I'm going to start polishing up my resume, because I'm working for an organization that employs lunatics. Happily, that wouldn't happen in the hardware world; unhappily, I'm a software developer rather than a hardware designer.
Which no client should/would have been using (given the error they would have received). Why would this new implementation be presumed incompatible, when any reasonable person would think this is an addition to the interface, and not a difference to the existing interface?
Almost certainly, the behaviour for all possible values that could have been passed to the function has not changed, merely some new ones have been added. If that's true, then Hickey is right, it shouldn't be considered a breaking change.
If at the same time as increasing the domain of the function, some of the return values changed for some possible values, then it is a potentially breaking change (although one not necessarily reflected in the API), and needs to be communicated. Whether it really is considered a 'breaking' change will depend on a fuzzy evaluation of whether it was legitimate for the client to make such assumptions about the return value, and will most likely depend on how the function was documented.
That case, where the function returns different values to what it used to, and which may break code that had expectations about those values, is a change that can happen any time and is not really related to the question of what to do when a function domain increases.
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.