Jakub has been around software development for past 10 years, wearing multiple hats, getting hands dirty in multiple environments, securing both technical as well as the business side of The Thing. “An engineer with a human friendly interface?”. Some languages, some frameworks, blah blah blah - doesn’t matter. Architect, programmer, manager, technical trainer, tech lead, wannabe entrepreneur, JUG member. There is a fair chance he does non of those those right.
Jakub always considered programming as a tool to solve real-life problems - in a pragmatic way. He always stayed closed to business side of the solution, still focusing on the technology. He combines daily job of leading the architecture practice at Young Digital Planet with lectures, technical trainings and comittment to Gdańsk Java User Group.
Czy zastanawiałeś się kiedyś co robia managerzy w Twojej firmie? Można decydować o wszystkim i mówić innym co mają robić, płacą pewnie za to kupę kasy i tak naprawdę nie trzeba robić nic. Brzmi jak robota marzeń!
Jednak z jakiegoś powodu dużo ludzi zawraca z tej scieżki kariery i decyduje się na powrót do developementu, Zastanawialiście się dlaczego?
W trakcie tego panelu, porozmawiamy z kilkoma liderami naszych community, którzy wkroczyli na tą ścieżkę i są tam albo z niej zawrócili. Czego się spodziewali, co zastali, czy warto?
Odpowiedź na te i kilka innych pytań postaramy się znaleźć wspólnie, co może pomóc wam w dalszym wyborze ścieżki kariery.
That sounds like an easy-to-answer question. A set of Java / Ruby / C# / Scala / Whatever tokens you mashup together everyday to get the business happy, right?
If you are in the business long enough you know there are rules, there are means to keep you code clear, nice, readable. You know to comment the stuff accordingly. You know to commit and push at the end of the day. And what you push is what you call "The Code".
But as you pursue through the developers professional career you start to notice that other things are becoming somehow important. It's not just The Code you need to pay attention to. It can be configuration, database changes and test data.
Than you look after requirements (like BDD being the tip of an iceberg - the behaviour part), documentation (models - the static parts). When you are all done, sometimes it's required to throw all over the wall to operations; so you are busy with check-list, manuals. You start to notice these all need the same attention as The Code, but it just got spread through some bugtracks, wikis, shared drive, network shares - becoming an unmaintainable hydra.
But you want it all in one place, because there all is became the code you have to mother.
In this presentation I'll go through some elements of code, not The Code itself. Share some ideas what can be done with requirements, documentation, check-lists, infrastructure - to keep it all in a single place, maintainable and accessible by all the stakeholders - in a way they like it.