Three days of focused opportunities for learning and networking.
DevConf is one of Poland's premier annual conferences dedicated to software development. It's based on principles we believe are the success factors of an ultimate conference experience. Regardless of technology, we strive to spark inspiration by exchanging ideas. We facilitate learning as a process occurring at talks and during informal conversations. Knowing that great sessions are not enough we're also eager to provide excellent networking opportunities. People and interactions are what we value the most.
The whole event is divided in to parts: pre-conference workshops happening on 25 Sept 2019 and the conference itself on 26-27 Sept 2019.
Meet our professionals.
More speakers still to be revealed.
Some attendees join us also for a bit more in-depth and hands-on knowledge. As a response, we organize workshops a day before the conference.
Tickets are being sold separately, regardless of the conference ones.
Conventional wisdom seems to be that the world is changing at an alarming rate. Technology is evolving rapidly and businesses better keep up or risk annihilation. As technologists, we are called upon to fight in the front lines of this impending revolution. Bring us disruption, they say. Think out of the box, they demand. The question that begs the asking - whose ideas are we actually disrupting? From whose suffocating box must our thoughts dare to break free? A conflict of interest arises when those that must usher in radical change have their identities intricately intertwined with the technological relics that must be left behind. When we speak of a revolution, we assume it’s targeted at some external repressive authority. But when it is our own work and our once brilliant ideas that are standing in the way of progress, the first battle we must fight is with our own ego. How do we let go of what once brought us glory and embrace the vulnerability of repeatedly feeling like a novice?
Star Wars. Minority Report. The Good Doctor. Ready Player One. Back to the Future. Hollywood has shown us visions of the future for years. Some of those visions are coming to life today, and it's changing the way we view the world… literally. Join me as I show you what mixed reality is, how it will change the future, why we have to be careful with it, and how you can get started with it today.
Serverless computing or FaaS is one of the most popular areas in the cloud nowadays. That is because if it delivers what it promises, we are looking at the next big thing. But, is it the case? As someone who has experienced how Serverless/FaaS has evolved in the last three years, I’ll talk about how it all started and where it is going now. There will be some fun and real cases where Serverless caused us problems and empowered us going faster. After sharing some of my experiences, we’ll try to answer or get even more confused on the future of Serverless!
Deploying a single container to the Azure is easy; running a mission-critical system is not. To run your ever-changing software reliably, you’ll need to think ahead about a range of things. For example, controlled deployment and testing of not only software but infrastructure as well. How can you use redundancy and cut dependencies to make both infrastructure and software resilient to failure? What do you do to monitor system health? And how do you protect your application’s secrets?
In this talk ‘from-the-trenches’, I’ll show you what you need to know, using Azure Kubernetes Service, Azure SQL, Application Insights, and more. I’ll explain how we chose to do it, what went wrong and how we fixed it.
The greenfield project started out so promising. Instead of devolving into big ball of mud, the team decided to apply domain-driven design principles. Ubiquitous language, proper boundaries, encapsulation, it all made sense.
But along the way, something went completely and utterly wrong. It started with arguments on the proper way of implementing aggregates and entities. Arguments began over project and folder structure. Someone read a blog post that repositories are evil, and ORMs the devil incarnate. Another read that relational databases are last century, we need to store everything as a stream of events. Then came the actor model and frameworks that sounded like someone clearing their throat. Instead of a nice, clean architecture, the team chased the next new approach without ever actually shipping anything.
Beyond the endless technical arguments it causes, domain-driven design can actually produce great software. We have to look past the hype into the true value of DDD, what it can bring to our organizations and how it can enable us to build quality systems. With the advent of microservices, DDD is more important than ever - but only if we can get to the good parts.
Picture this: you're a senior engineer at your company who, one day, is thrust into the architect role. Suddenly, you're having to think about things that you've never thought about - what's the difference between a microservice and a service bus? How do I design a scalable system for tomorrow without overengineering today?
Better yet, if you're at a startup, do all that - and still be responsible for code reviews, development, and coaching of junior devs. How can a fledgling architect possibly "do it all" - and more importantly, do it well?
Luckily, someone has gone down that path (and is still going)… and he's ready to share his story.
Attend Spencer's talk and hear about how he, as a senior engineer, had to grow into the architect role. We'll discuss the problems faced, the critical "decision points" he made from an architecture standpoint, the results of those choices, and how he helped guide the business through three architectural rewrites - all in a span of four years!
Software and technology has changed every aspect of the world we live in. At one extreme are the ‘mission critical’ applications - the code that runs our banks, our hospitals, our airports and phone networks. Then there’s the code we all use every day to browse the web, watch movies, create spreadsheets… not quite so critical, but still code that solves problems and delivers services.
But what about the code that only exists because somebody wanted to write it? Code created just to make people smile, laugh, maybe even dance? Maybe even code that does nothing at all, created just to see if it was possible?
Join Dylan Beattie - programmer, musician, and creator of the Rockstar programming language - for an entertaining look at the art of code. We’ll look at the origins of programming as an art form, from Conway's Game of Life to the 1970s demoscene and the earliest Obfuscated C competitions. We’ll talk about esoteric languages and quines - how DO you create a program that prints its own source code? We’ll look at quine relays, code golf and generative art, and we’ll explore the phenomenon of live coding as performance - from the pioneers of electronic music to modern algoraves and live coding platforms like Sonic Pi.
Chaos Engineering is methodology that experiments on a distributed system in order to build confidence that the system will work well in production. Essentially, we experiment by trying to break our system to uncover system weakness.
In this talk, Paul will cover the basics of Chaos Engineer, give some case studies of companies that currently do this in production and give an introduction to some of the open source tooling that currently exists so that you can maybe try this at your company. Paul will also show that, by following good infrastructure management practices, that you can recover and scale the system when necessary, easily!
Embracing DevOps entails more than just shipping changes to production faster and faster. Your team is suddenly also responsible for monitoring your software in production and detecting and troubleshooting issues. To work together with operation specialists in your team or maybe even embrace a #NoOps approach, you as the developer, need to learn about monitoring.
We will discuss logging frameworks and log analytics solutions. Next to that we will explore metrics: your software’s KPI’s. What metrics to choose and how to gather them. To let information come to us, we will use both logging and metrics to create dashboards and alerts that notify us when things go south. Or better yet: before things go south! Finally, we will combine all of this to see how we can quickly investigate and resolve production issues.
Join Henry Been for a demo heavy session, including like NLog, Application Insights, Seq and more to see how to implement all of the above from scratch. During this session, you will learn everything you need to know to start monitoring your solutions and never lose any sleep ever again!
Feature toggles are a great asset to your development workflow - they make experimentation and incremental changes easier and help push features through faster. But there are potential problems: old flags, unused flags, or worse, re-used flags can come and bite you when you are least expecting it.
This talk will cover how to use feature toggles effectively, cover some of the horror stories, how they can be avoided, and how to deal with them if they do occur. Examples in C#, but applicable everywhere.
“Microservices” is certainly a buzzword. Everybody wants to work on microservices applications. However when working on such a project you’ll soon realize that a buzzword doesn’t magically make your application work. And there will be a lot of challenges that you’ll face on this journey. During this session I will share my experience from the trenches of a microservices project aiming to make developers aware of the different challenges they mostly won’t see at conferences. I will also try to illustrate my experiences with relevant code samples.
The talk starts out setting the stage by a brief discussion of the 3 benefits microservices can bring, which is all about the flexibility the business gains through short lead times, ability to experiment and ability to scale. The main part of the talk is arund 3 concrete rules of thumb that guide decisions around what the responsibility of a microservice should be and a whether new ones should be introduced. Each rule is explained used examples I have encountered in real life projects. The 3 rules are
Using these 3 rules, in my experience, leads to microservices that allows us to realize the benefits of microservices.
To round things off I explain tactics for for fixing the scopes of services when we get then wrong. Again there is good rule of thumb to follow, namely that when in doubt error on the side of slightly too large. I will show why this is a sane rule to follow.
In Shedul/Fresha: we’re not doing Scrum, we’re not using a commodity language / development platform, our architecture is neither a monolith nor micro-services, we don’t have HR / Recruitment dept or even formal “bosses”. We’re not following any hype or re-inventing everything from scratch either. And despite all these NOTs, we’re a serious engineering bunch on a continuously raising curve (for 4 years already), having a consistent exponential growth (business activity volume) month-to-month. How come?
Instead of copying unicorns, we’ve started with very simple solutions & are applying self-disciplined Continuous Improvement (Kaizen) to adjust them to our local needs, specifics & conditions. That’s how Triumvirate was born, that’s why we use Elixir, put our Architecture under Scalpel, follow the Bossless style of ownership, put everyone’s Skin in the Game, found our Hedgehog Concept, etc.
The purpose of this talk is to convince you that copying 1:1 what has worked for other companies does not make sense, neither does mindlessly following consultants’ “best practices”. What works much better is building high internal awareness of your work, measuring what matters & continuously learning (& improving!) via series of small, time-bound experiments. This thesis will be backed up with the series of “war-story” examples of how we’ve evolved something towards (usually) the better in a sometimes very un-obvious way :)
Do you believe political correctness and empathy are buzzwords that limit the society rather than contribute to its advancement? Do you think talking about topics like diversity quotas, privilege doesn’t make much sense and you would rather spend this time talking about the latest in technology?
In this talk I would like to take the chance to try and add the missing contexts to such terms and arguments, moreover, I will try to go through various examples on how it can impact your product from a very pragmatic prospective.
WCF may be no more, but there are still countless legacy systems that only speak SOAP, and new code still needs to talk to them. As part of the Visual Recode project, we're providing a brand new SOAP client generator for .NET Core 3.0; one that uses the full range of new, high-performance features of the modern framework. We've got Pipelines, Channels, Buffers, Pools, Spans, the works. In this talk, I'll show you how it all works together to create a client that uses less than 1% of the memory used by the old WCF client, and how you can use these new components to improve your own projects at all levels.
Quantum Computing is coming. Or is it already here? People say it has the potential to completely change the world, but will it? When? How?
In case you haven’t heard, quantum computing is an emerging field that uses a quantum system, like the spin of an electron, to do a very specific type of math. Until recently, they had only been theorized, but advances in physics and engineering have caused rapid advances in the field. There are no fewer than a dozen companies working on quantum hardware and control, and probably twice that working on algorithms and practical applications (to say nothing of the many, many, academic labs that have been working on these problems for decades).
Every few months, someone claims a larger, more powerful device. Promises of “quantum supremacy,” the death of RSA, and a complete paradigm shift are on the horizon. How much should you, as a random technically-inclined person, care about all of this anyway? What do you need to know, and what can you just leave to the experts for now? What can you leave to the experts forever?
We’ll answer seven main questions:
We won’t be covering:
Who should attend:
Anyone who is curious (or scared, or excited) about quantum computing, but doesn’t know much yet. Maybe you’ve read a few articles on Wired or Gizmodo, maybe they’ve left you with more questions than answers. No prior knowledge of physics, quantum computing, or advanced mathematics necessary. A basic familiarity with how classical (“regular”) computers work is helpful, but not required.
What you’ll leave with:
A more comprehensive knowledge of quantum computing, both from a big-picture—history, major players, practical utility, progress, what’s next — and a nuts-and-bolts—qubits, algorithms, hardware—perspective. You’ll be able to say “yes!” when your boss asks if you know anything about this quantum computing thing, be able to not only understand, but critically evaluate announcements and headlines about quantum computing, and if you want, a bevy of resources for going deeper into this emerging field.
Whether we use high-level languages like Java, Python, C# or we dive into the world of C/C++, the lists of dependencies of our projects contain more and more external frameworks and libraries. It makes developers’ life easiest and helps us to focus on delivering business value. Do you know what vulnerabilities are known for the version you use? Are you sure you know all the tips and tricks to use the framework in a correct way? Is it good for our software to rely the security of our products on the security of these frameworks and the way we use them?
Join me during an exciting LIVE DEMO. Get to know how to weaponize known Spring Boot Data Rest library vulnerability. See how to use Remote Code Execution to actually fully compromise the server hosting an application.
Using the vulnerability in an actual attack helps us to understand the underlying mechanism and find if it is applicable to our software. It also allows us to find the detection patterns if it is attempted to be exploited on our infrastructure. And besides all of it – it is fun to hack the servers! It also shows that we can do much better than just blindly upgrading components. There are examples of vulnerabilities, which are fixed not with a single patch, but rather through a series of upgrades leading to more secure solutions, so it is important to stop for a while and think about other attack paths and consequences, that can be faced. The reactive approach of simply keeping up with the latest version leaves us in a position, where we are always exposed to new vulnerabilities that are about to be discovered.
We are all human and we all have our sins. In our professional lives as well. Unfortunately we do not realize many of them, and even the smallest ones, can have a negative impact on what is happening in our everyday work and our teams. Committed, over and over again, they affect everything that is important in our projects both from business and technical perspective. These small bugs in our behaviour can lead to worse requirements understanding, bad decision making and decrease technical quality. During the presentation, I would like to share my observations and thoughts, which sins to avoid and what to pay attention to, not to land in the coder's hell.
Most of developers work on web, mobile or desktop applications, but in today's world software is everywhere - also in aeroplanes, space shuttles, medical equipment or nuclear power plants. How software development in these fields differs from everyday applications? How developer's work looks like when he must comply with restrictive regulations? During my talk I will answer these questions using my experience in the field and references to normative documents. I will also analyse some software errors causing loss of human life and destroying equipment worth millions of dollars. I hope that this presentation will be useful to every developer and will help you to create safer and more reliable software.
Accessibility is just becoming an important topic in web design. There are more speakers talking about web accessibility, and this is a very good fact! Standards like WCAG and applications like ARIA are doing good work. But there’s more in life than web applications, we are in the app century! Apps can be designed and developed with an accessible approach. Welcome in this talk about designing accessible apps! It doesn’t matter if you are an iOS, Android, Swift, Java, C#, Windows,.. developer, all the design techniques we are describing are universal idea’s that you can implement in each language or system!
Information is everywhere and for many people, especially in the connected world, it is accessible freely or at a minimal cost. News outlets rely on social media to broadcast breaking news. Social media in turn relies on us to feed it with information, be it of our surroundings or our personal information. It’s become somewhat of a self-sustaining self-serving machine in which we’re all part of. It’s big data and we’re a cog in the wheel. For now of course, because with big data and cheap yet powerful hardware, AI also wants to play the game.
And if information and knowledge is the key to success, surely this means we’re on the right path. The question is, will we notice some of the warning signs before it’s too late…
Callum will share the process followed and challenges faced from incrementally rewriting a large monolithic medical system (used by the NHS and other global health institutions) into a majestically constructed microservices architecture.
He’ll discuss how the team identified, prioritised and replaced key components of an existing application as independent services; the difficulty but importance of refactoring the legacy codebase to be event oriented, methods used to effectively “strangle” parts of the live system as they were replaced, and what the team needed to do to rapidly scale up a creaking system against a tight Christmas deadline…
He will also take a look at the infrastructure components used to quickly get a large microservices system up and running, focusing on utilising Azure Functions and API Management Gateway, and touch upon the learning curve that working with these unfamiliar technologies had on the growing team.
It seemed like an easy feature to implement, a checkout page to place an order. But this payment gateway has a simple API, so we added that. And this email service provider makes it possible to send an email with one line of code! Finally we can notify downstream systems via a message queue. The code looks simple, 6 little lines of distributed systems code.
But those lines hid a dark secret that we only found after launching. Customers complained they didn’t get their email. The back end system wasn’t getting updated from our messages. And by far the worst of all, customers complained they saw an error page but still got charged!
Clearly it wasn’t as easy as calling a few APIs and shipping, we actually need to worry about those other systems. In this session, we’ll look at taking our 6 lines of distributed systems fail, examining the inevitable failures that arise, and possible mitigating scenarios. We’ll also look at the coupling our code contains, and the ways we can address it. Finally, we’ll refactor towards a truly resilient checkout process that embraces, instead of ignoring, the fallacies of distributed computing.
Azure Functions is a key part of Microsoft serverless offering. At its core, it is a compute service, but its real power lies in integration capabilities. A lot has been said and written on how to use build in triggers and bindings to connect with databases, queues, web requests, and third-party APIs. There is however one aspect of Azure Functions which has been neglected - extensibility. This talk will walk you through Azure Functions extensibility with practical examples. It will give you the tools to push its integration capabilities further and get even more from Azure Functions.
We know how to write code to do something now. What about code to do something tomorrow, or next year? Sometimes we use batch jobs. But as business grows, our “overnight” batch job starts finishing around lunch time. As we expand to new regions, we realise there is no “night”. And it’s only a matter of time before we make a change and break a batch job we forgot existed. What if tomorrow’s code could live in the same place as today’s code? What if it all looked the same? What if we could scale it all the same way?
Join Adam and discover how to embrace the future in the code we write now. Learn how to capture requirements as first class business logic, and avoid relegating them as second class citizens of the batch job world. Take a deep dive into techniques which combine off the shelf products with fundamental computer science.
Where we’re going… we don’t need batch jobs.
REST APIs aren't dead - in fact they're more alive than ever. Don't let the hype around GraphQL put you off - RESTful APIs are being built and used by developers all over the world and that isn't changing anytime soon.
Before you start with File > New Project, however, there are some key decisions to be made about your API. Who is the main consumer? How will you authenticate? Who will own the documentation? How will you test it? How will you deploy it?
In other words, how will you manage the (probably very long) lifecycle of your REST API?
Join Spencer as he walks you through some of the decision making processes that you'll go through when building a REST API from the ground up. He'll offer advice as a designer of REST APIs of all shapes and sizes, for many different kinds of consumers, and share some of the many lessons learned over the years. Finally, we'll walk through some of the technical considerations you'll make when your developers finally sit down and start developing your API.
2019 is the 30th anniversary of my first job in tech. On my first day I was given a Wyse 60 terminal attached via RS232 cables to a Tandon 286, and told to learn C from a dead tree so I could write text applications for an 80x24 character screen. Fast-forward to now: my phone is about a million times more powerful than that Tandon; screens are 3840x2160 pixels; every computer in the world is attached to every other thing with no cables; and we code using… still basically C.
Having lived through all these changes in realtime, and as an incurable neophile, I think I can make an educated guess as to what the next 30 years are going to be like, and what we're all going to be doing by 2049. If anything, I'm going to underestimate it, but hopefully you'll be inspired, invigorated and maybe even informed about the future of your career in tech.
Coders code. That’s what we do. We write functions and classes and modules and we conjure amazing systems out of thin air. Electrons dance at our command; with a few keystrokes we can solve the most complex calculations, find hidden patterns in the data of our everyday lives, and send information flying around the planet at the speed of light.
The world uses our code to book flights, pay taxes, talk to friends and family… and before too long, our code might be driving cars, diagnosing illnesses and convicting criminals. Code runs the world. And when our code goes wrong, the solution is almost always… more code. We ship millions of lines of code every day - and, in these days of smartphones and networks and IOT, a single line of code could be running on millions of devices within minutes of us deploying to production. But have you ever stopped to consider the real cost of those lines of code? Your code might end up running in production for years, maybe decades.
It’ll become one small part of a giant global codebase that’s using literally trillions of processor cycles and hundreds of billions of kilowatt-hours of electricity every year. A codebase that’s hiding countless vulnerabilities, flaws and dependencies. A codebase that's driving users to buy millions of new laptops and smartphones and tablets every year because the old ones are too slow, or won't run the latest apps. A codebase that is literally changing the world we live in - and not always for the better. Join Dylan Beattie at DevConf 2019 for a stark, sobering look at the real cost of the code we’re shipping every day. What’s the real cost of code - to our organisations, to our society, to our environment? How can we help our teams and users understand that cost? And what can we do to reduce it?
Machine Learning is a fast evolving discipline and one of the hottest areas both in industry and academia, and it only keeps getting more traction. With such a quickly advancing field, it becomes increasingly hard to keep up with the new concepts.
If you find yourself lost in a forest of ML buzzwords and want to get an overview - welcome to this session!
You will get the gist of the most interesting trends in Machine Learning - from AutoML and ML bias to GANs - with zero formulas and maximum sense.
ML.NET is still fairly fresh Microsoft venture into deep learning. It's written in .NET Core and a lot of good thinking went into it. It's definitely the best hope for .NET developers to do machine learning natively and easily incorporate it into existing apps. CNTK is another venture into ML for Microsoft, that allows you better control over what you're doing.
And to show the power of both of them, we'll harness deep learning to help a metal band to get out of their rut by writing for them some awesome new riffs.
From this talk, you'll learn how to use ML.NET and CNTK, how some deep learning techniques like Recurrent Neural Networks work and how to write a metal songs!
Machine learning and artificial intelligence are becoming wide-spread and productionalized - you no longer need a mathematics PhD and months of software development time to implement and use a machine learning algorithm. You can just call an API and you get the answer! You can treat them completely as black boxes and use them directly in your applications! But beware - all the algorithms have some cases when they fail to deliver what you're expecting. This talk is packed with live demos that show failure cases of popular algorithms, from linear regression to cutting-edge deep learning. I will look at practical examples, use standard algorithms as black boxes and observe when they fail and why. You will learn that although you can treat the algorithms as black boxes, they can fail silently and what to do about it.
We are used to having safe references and not bother with memory leaks. CLR or JVM take care of allocating objects and verifying that we do not do illegal instructions. Worst thing we can have is just an exception which usually we can catch and handle. But what if we want to take care of lower mechanisms? Do we need to use C++ or can we stick to our favorite language and trick the platform to execute any code we wish?
Since we can allocate memory and our machines usually don’t differentiate between code and data, we just need to modify few pointers to execute any code we like and allocate objects wherever we want. We can do it in C# or Java, and most likely in different languages as well. At the end it is just a bunch of bytes we run and modify.
And when it comes to C# details, during the session I will show how to allocate memory directly by hand using TypedReferences. We will see that it is possible to allocate reference type on a stack, how to hack new keyword provided by the platform to use different allocator, and how to execute any machine code using pure C#. We will examine memory dumps with WinDBG, emit IL code dynamically, and generate machine code for x86 directly in runtime.
The title of this talk sounds like a quote you would attribute to some ancient
philosopher, or perhaps something taken off a motivational poster. When it
comes to mixed reality and holograms, persistence is really where the magic
starts to happen in your brain. First we are going to explore why that is.
Second we will talk about why solving the problem digitally is interesting.
Third we will discuss the tools that can be used to make digital content persistent.
Finally, we will talk about using persistence responsibly.
You may have heard development teams talking about the number of deploys they make a day or the number of PRs merged a day. You may have heard marketing teams talk about the number of page views a day. What do these metrics even mean? Are they actually useful to the business as a whole?
In this talk, Paul will debunk the idea of “vanity” metrics and why using these as a guide to success has only one outcome. This is a talk intended for all parts of an organisation to really help understand what metrics can do for us and why a metric may not mean what you believe it does
Behind every vanity metric is a real metric that can help us understand the health of our company - whether it be the ability to understand our users or the ability to understand the value of a feature
We just need to step back and think about what it actually is…
"You are not your code" is oft repeated. The sentiment is invaluable, but insufficient. "Your code is not your data", I say! Take a stroll with me through some anecdotal projects to learn why you should stop squabbling over code techniques and start scrutinizing your data abstractions. For that way only shines the light in the tunnel of despair that is our daily programming grind.
The fundaments of nations and society are shifting in the foot steps of technological evolution. What will this mean for humanity as a race?
We are on the cusp of a new evolutional stage - the post human age of the netocratic dividual where social networks determines your status and the tribe surplants the nation state as the defacto seat of power.
How will this change us, both as people and profession, and how does one lead when no-one really knows where we're going?
With Kotlin target the JVM, Android, JavaScript and now with Kotlin/Native targeting other platforms such as iOS, macOS, Windows, Linux, the possibility of targeting multiple platforms with a single project is now a reality. In this talk, we’re going to cover how you can create multi-platform projects with Kotlin, what is provided as part of the language as well as what is made available in libraries.
In this talk I show some internals of exceptions. Examples are based on typical use cases and common mistakes. I show why calling async methods synchronously might be a bad idea, how to catch out of band exceptions or how to implement synchronization mechanisms to wait for async void. We know that we should have “async all the way” but very often we are forced to have some trickery because of frameworks we use.
Do you think you don’t deserve most of the success you have achieved? Are you afraid people will soon realize that you are not as smart as you make yourself out to be? Do you find it difficult to accept compliments? Impostor Syndrome: does it concern you? What actually is the Impostor Syndrome? What are the symptoms and how to cope with this syndrome?
Are you frustrated because your ideas about new tools, frameworks, practices
are not picked up by your fellow developers?
Do you notice flaws in organization and your manager doesn't want to listen
to you?
You don't know why your mate behaves way he does?
Are you angry because your code review remarks are considered nitpicky?
85% of your success depends on emotions. For some people sooner for some people later the way they handle other people will be a blocker for further development not only as developer/manager but also as a human. It is most probably that this will impact your career (promotion or even job lost).
I have seen this multiple times during my over 11 years career as software engineer and felt it on my own skin. If you would like to get next level on your career path (of course connected with promotion and salary increase), this session is dedicated for You!
I will show you entry point for fundamental techniques in handling people, ways to make people like you, win people to your way of thinking and how to change people without giving offense or arousing resentment to give you another powerful tool to handle daily situations.
Get yours while they're still available.
Workshop ticket doesn't include a conference one.
Looking for group discounts?
Use one of the following codes during registration.
Discounts do not add up.
* All listed prices do not include 23% VAT
See what we did in the past.
Take a look at 2017 and 2018 or check out the full gallery.
Companies that support us.
If you or your company would like to reserve a spot as a sponsor, contact us because we might have a good deal for you.
Communities love.
Read more about our diversity scholarship.
Multikino, Dobrego Pasterza 128
Kraków, Poland
From the very beginning we've been focused on people, not on companies. Being developers ourselves we thrive to provide the ultimate experience that will be remembered. We'd like to connect awesome speakers with the willing-to-learn-and-share community. It's not only about sessions - it's also about meeting with like-minded people - it can result in great ideas, is that right?
DevConf Team
Grzegorz Duda Developers World
ul. Wielicka 91/4
30-552 Krakow, Poland
VAT ID/NIP: PL6792536646
Registration Number/Regon: 120770736