Tal Joffe
Software Development Manager at Amazon
Tel Aviv, Israel
Actions
Tal is leading software projects and teams for the past 12 years, currently as a development manager at Amazon.
Tal is trying to combine his passion for technology and methodology to create happy, effective teams that deliver great results.
Tal usually writes and talks about clean code, design best practices, functional programming, and software testing.
In his spare time, Tal listens to many podcasts and will happily talk about them
Area of Expertise
Topics
Never design against requirements
Yes, you read it correctly.
When I first heard this sentence I didn't get it too.
But when I looked back on all the systems I've seen start as small and simple, and become a monstrous legacy, I realize that not being able to adapt to changes in requirements was the cause.
In this talk, I will share what not to do when it comes do design and will show my methodology that will help make sure your design stand the test of time.
Building software that scales with Typescript
Typescript was built by Microsoft for this very purpose - helping developers manage large and complex Javascript codebases. But simply using Typescript will not magically make your code scalable. In this talk I'll explain some key architecture and implementation principles that can leverage Typescript abilities and allow your Javascript code to scale
All you need it types
Typescript was created by Microsoft to help enterprise C# developers write OOP code in Javascript. For that reason, many typescript codebases look a lot like C# or Java code.
As a brown belt in functional programming, and a fan of the KISS principle, I try to use Typescript differently.
A functional Javascript programmer doesn’t have to use classes and interfaces. A combination of types and functions will do the trick.
Shared services - good idea? or bad idea?
A shared service is a service that handles a common behaviour, used by different domain-specific services so that they don't all have a similar implementation of the same thing. Sounds good right? But did you ever ended up with such a complex shared service that adjusting it to new features takes 4 times as long as doing it on the domain-specific service? we did.
In this postmortem I'll share how good intentions were not enough and what have we learned from working with over complex shared services
Why every web developer should learn software design
With modern frameworks, building an end to end solution can be done with very little lines of code. This makes delivering a working MVP fast and easy but when requirements add up, and the product is shifting, our cute little app turns into a monster.
This phenomena happens because the complexity in our work as developers is shifting from the low level implementation to the high level design. If we don't design our system well enough, it will not age gracefully no matter how well we know how to implement sorting algorithms and to encrypt messages.
in this this talk I will share design methods and principles every developer can use
Empower developers and streamline delivery
Traditionally the development process of a product or feature is being passed around between people with different roles - Scrum masters, Architects, developers, QA, DevOps, etc.
By empowering developers to do most or all of these responsibilities we allow for a streamlined process.
You can rightfully argue that a QA professional, for example, will be much better on average than a developer in finding bugs but in some cases, the cost to the process and the lack of flexibility is greater than the benefit.
After working this way for a few years I want to share how we managed to get this approach working for us and where we are still trying to improve.
I'll also share what this approach does to the culture of an R&D organization and what can we benefit from it in terms of growth opportunities and retention for developers.
Scary functional programming terms made easy
Are terms like Monads, Currying, and point-free-programming thrown at you, and you have to smile and nod until it’s over?
Well, smile and nod no more!
In this talk, I’ll explain with simple words, pictures, and Javascript examples (no Haskell, I promise) what these terms mean and how are they being used.
Micro-feedback
I'm sure you all know about the benefits of "Micro-Services" as opposed to the dreaded Monolith.
In this talk, I will use this technical analogy and a few more to help you break down performance review into small ("micro") feedbacks that shouldn't take more than ten seconds.
As technical leaders, we have a tendency to approach technology in a much more methodological way than we do leadership and as I'm sure most of you have experienced already, it is not because managing people is super easy and intuitive that there is no need for method and guidance.
I will give simple to use principles and guidance on how to give (micro) feedbacks that actually works
Never design against requirements
Building an application quickly is easy and there are many tutorials for that.
Building an application that will gracefully handle requirement changes over time is the tricky part.
In this talk, I will explain how to create and implement an architecture that is structured around the volatilities of the solution and not its functional requirements.
We will talk about a methodological approach to building such an architecture and some tips and guidelines on how to implement this architecture in a real-life project
Practical functional programming in Javascript
Have you always wanted to learn what functional programming is? Do you think you understand what it means but not why and how to use it? Are you a functional programmer but cannot convince your team to get on board?
If you answered yes to one of this question you should join this session!
I will use plain words and day-to-day Javascript examples to try and explain the core principles and how they can help us create clean, scalable Javascript applications
Should software engineers be creative?
Early on in my career, I was often encouraged to "think outside of the box" and develop creative solutions to problems. As time passed, I realized this might be the worst advice to give software engineers. When you consider that we spend most of our time reading code, one of the most important aspects of a good codebase is predictability. Senior developers know to follow standards, best practices, conventions, guidelines, and so on, so does it mean we don't need to be creative?
Well, sometimes we do, and sometimes we don't. The trick is to know when.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top