Coding Architect
Clemens Stift
Software does not exist in a vacuum - it serves the goals of the organisation it is created for. Great software is deliberately built with an acute awareness of it's context.
Software does not exist in a vacuum - it serves the goals of the organisation it is created for. Great software is deliberately built with an acute awareness of it's context.
I started out my career on a clear track towards strategy consulting before I took a hard-left and transitioned into deep technical work in big technology consulting organisations. Getting access to incredible opportunities to code, architect and lead in both large-scale IT transformation projects as well as new product development efforts in fintech, medtech and banking.
As an architect and engineer with an MSc in Management of Innovation & Business Development I've always been, and continue to be, incredibly passionate about building great technology and putting it to good use. I believe that being independent is an asset for both me and my clients in executing on that drive.
.png)
Being at 5 million users and needing to scale load and organisation or carving out the organisational and architectural wiggle-room for a new initiative to flourish and find product-market-fit in the existing context require vastly different approaches. Getting the balance between pragmatism and future-proofing right is hard. Keeping avenues to evolve the software into the next stages even harder.
I bring experience and knowledge in defining target architectures, planning the transition and assist you and your teams in executing on it without delivery grinding to a halt.
Teams are the heart of continuous software delivery practices - a well-working team is invaluable. Getting teams from good to great, be that in terms of technical expertise or mode of operation, is a worthwhile investment.
With years of experience and industry best practices - I accelerate project timelines whilst facilitating knowledge transfer and enhancing the capabilities of your in-house developers.
1export class LlmChatComponent {
2 @Input()
3 public systemPrompt = '';
4
5 @Input()
6 public openingMessage = '';
7
8 @Input()
9 public rememberChat = false;
10
11 public models = [{...}]
12
13 @Output() messageAdded = new EventEmitter<number>();
14 public llmSelectionVisible: boolean = false;
15
16 public toggleLlmSelection() {
17 this.llmSelectionVisible = !this.llmSelectionVisible;
18 }
19
20 public onMessageAdded(event: number): void {
21 this.messageAdded.emit(event);
22 }
23
24 public COLLOQUIAL_DEFAULT_MODEL_NAME = "Mistral";
25
26 public selectedModelId: string = this.models.find((model) => {
27 return model.title.includes(this.COLLOQUIAL_DEFAULT_MODEL_NAME)
28 })?.modelId!
29 public selectedModelIndex: number = this.models.findIndex((model) =>
30 model.modelId === this.selectedModelId);
31
32 public onSelection(event: {modelId: string}) {
33 this.selectedModelId = event.modelId;
34 this.selectedModelIndex = this.models.findIndex((model) => {
35 return model.modelId === event.modelId;
36 })
37 this.toggleLlmSelection();
38 }
39}Product Engineers are a special breed of engineers that do not just see themselves as coders or developers but as builders who deeply care about the products they build. The craft combines Product Thinking with technical execution.
I take great professional pride in the products I build. Understanding the user and thoughtfully validating the value proposition the product embodies for the user is paramount - giving a beat on the level of uncertainty your initiative is faced with and allowing us to adjust engineering efforts accordingly.
A glimpse into my thinking over the years. Some of it might age like a fine glass of milk, but I am putting it out there nonetheless.
Experience shows me that the most effective way to do my job is to join a team and deliver code together with them. Be that in a new initiative, in an architectural transformation or when working to introduce new ways of working to an org. It gives me the chance to experience bottlenecks in delivery myself, is a great reality-check for whether a designed solutions actually work in practice and leads to the best adoption of new ideas by primarily being a team-member as opposed to "an external".
I'm first and foremost an Engineer and Architect. As a consultant going from one organisation to another you don't choose "your stack" - you become really good at learning the ropes really fast and understanding which skills and patterns you can and can't transfer between the different ecosystems. The Engineering knowledge and skill remains. It would be a lie to say the language and Ecosystem don't matter - but they are not an insurmountable challenge.
Languages in which I've shipped to production: Java, Kotlin, Typescript, PHP, Python, Go, Dart.
Technically, yes. I like to use the term "independent consultant". I am currently learning what expectations for Freelancers exist out there but I already have the feeling that my expectations of leaving a long-lasting positive mark on the client-organisation is not often included. I consider shipping code a precondition for doing my job well. If I can and I'm allowed to, I like having a mandate to move more from that position.
I'm always open to discuss all things product and engineering. Feel free to get in touch!
Let's chat