DeveloperWeek PRO Stage C
Wednesday, February 17, 2021
Enterprise and industrial network components such as switches, routers, IoT gateways and even Wi-Fi access points are getting more and more powerful to run applications. Because of that more use-cases for edge computing scenarios are emerging.
This session will cover the current status of edge computing (true edge vs service provider edge vs others) and get into real-life use-cases of how various companies throughout several industries are already using their network components for edge computing.
For example, connecting various industrial machines, collecting indoor Zigbee/BLE sensor data, security applications and many more will be showcased. Furthermore, all used tools, technologies and how creating, deploying and managing containerized applications will be presented. And of course, there will be a real-life demo!
With serverless computing, you pay for the resources that your application consumes. The longer your serverless code runs, the more you pay. The longer your serverless code remains idle, waiting for a backend response, the more you pay. The longer your database handles a write-request sent by serverless code, the more you pay. At the extreme, the idle time of serverless functions can represent two-thirds of your monthly bill, and you question why somebody selected the serverless architecture in the first place.
In this session, you learn how to use in-memory computing to reduce idle time and accelerate the execution of serverless code. The provisioning of an in-memory cluster is a prerequisite, not a game-changer. Dramatic differences become apparent when you consider several tactics while fastening serverless code to your just-provisioned in-memory cluster.
Now more than ever, when the whole world is communicating on digital channels, the dangers of disconnected data silos and lost knowledge are more than ever. In this session, we will talk about applying deep understanding to capturing this open domain conversation data so that builders can strategize product strategy early in the lifecycle of their business and future-proof growth. The session also entails several aspects of supervised and unsupervised learning that can be used as stepping stones to this application and how combining both these techniques bring the best of both worlds together for human-like comprehension of conversations.
Through my career, I have seen and solved so many different computing problems. I find the challenge is not we can't solve large scale problems, the challenge is not we are lack of great tools. The real challenge is lack of consistency: solving different scale problems requires different programming models and frameworks, solving ETL and machine learning problems requires different skillsets, mindsets and even different languages.
In this session, I am going to introduce the Fugue project, whose purpose is to:
* unify the key concepts of distributed computing and machine learning problems
* unify the key interfaces for end to end ETL and machine learning pipelines
* decouple user's code and mindset from the underlying compute engines such as Spark and Ray and Fugue itself
I am also going to go through a couple of real examples how Fugue can shape your mind and optimize your code.
Fugue is already open sourced at: https://github.com/fugue-project/fugue
If you’ve been someone like me, been in the industry for a while, and have completed years as an engineer, you might have this difficult question: What’s next? Shall I continue on the technology ladder or explore the possibility of tech leadership path. A lot of companies like Intuit will have a career path split, usually after the senior engineer level: technical or management path. So which one should you pick? Usually, the choice is very clear for engineers who want to stay in technology. However, there are people like me indecisive, not sure which choice to make.
A lot of people deal with this dilemma, in this session, I will unpack of responsibilities to Engineer and Manager aspects of this role. For e. How as an engineer this role becomes the flag bearer of Operational and Technical Excellence of the product development. And as a manager make a high performing team by Hire/Grow and Retain and effective Team and People Management.
In the end - Technical managers are a special breed, requiring both technical savvy and people skills. It’s an interesting work, at times the technical aspects will need more attention, sometimes it’s the people aspects. In this leadership role, we can create a bigger impact than by writing code myself.
In this training session, we will learn how to convert best practices on performance and scalability to a cultural behavior and keep our apps at a performance state-of-art, preventing loads, and improving our emergency playbook.
We will learn how to plan, design, and execute preventive performance tests, collect, and interpret the right metrics and how to act on emergencies.
Thursday, February 18, 2021
Building and marinating a five 9s system isn’t just about the tools and technologies. Development culture has a big part in how you keep a system available while scaling it up and supporting more features, users, and locations.
A healthy learning culture, supporting the development, not repairing mistakes, and identifying weak points is another tool in the engineering toolbox.
In this talk, we will discuss how to create a learning culture using debriefs, what to avoid, and how to instill change in an engineering organization.
We hear it all the time; Management has a list of requirements for a new product line. The design team is tasked with designing; the dev team is tasked with building, and after reading 1,000 grueling feature requirements everyone reluctantly signs off on a release date.
Then the real fun begins. The design team gets creative. The dev team gets technical. Product requirements are incorrect (or missed), Ego’s collide, and the whole team stresses to meet rapidly approaching deadlines. Where did the communication break down? Why can’t team members all speak the same language? We’re here to tell you that they can, and it starts with process.
During this presentation, we’ll show you how to train your team to work more effectively together and how to establish a “common language” to overcome cross-disciplinary obstacles. This talk will highlight case studies, examples, and procedures the audience can use to better their lives and their product development lifecycle.
Features are the Future
Over the last 15 years, organizations have had difficulty with the entire software delivery process, but two artifacts in particular became a recurring problem. The problem stems from the Goldilocks principle: one of these artifacts is much too big to overcome efficiently, and one of them is much too small to make a significant impact, so we need to find the one that is just right.
The artifact that is much too small would be the individual build. In fact, organizations and individuals often obsess over the individual Build. Builds are important, but in the grand scheme of things, they are often too small to make a significant difference in a short period of time. The artifact that is often too big, that many are trying to improve with Agile practices, is the Release, which was an arduous 18-month-long process.
So what artifact is “just right?” As the user, what we really care about are the Features: the stuff we use and interact with all the time to make our daily lives better. However, the systems we have today haven't advanced to the point where software features are the nearest proxy for customer value. In other words, the feature must be at the forefront of the UI.
In this talk, I will share why features are the proxy for value and explore the different levels of abstraction for the “just right” aspect of a Feature in order to shift people's mindset from thinking in terms of Builds or Releases, to thinking in terms of the customer and business value. I will share tactics to address the Goldilocks problem and how to have these discussions at the right level of the software in order to make prioritizations, decisions, and discoveries.
What Attendees Will Learn:
A different perspective about software delivery, which will help them make better decisions about which features to pursue and builds/releases to postpone.
Learn why features are the future and how they are the perfect middle-ground between individual builds and major releases.
How to ultimately break free from the Goldilocks problem of software delivery.
Legacy software supply chain “exploits," such as the now famous Struts incident at Equifax, prey on publicly disclosed open source vulnerabilities that are left unpatched in the wild. Conversely, next-generation software supply chain “attacks” are far more sinister because bad actors are no longer waiting for public vulnerability disclosures. Instead, they are taking the initiative and actively injecting malicious code into open source projects that feed the global supply chain. By shifting their focus “upstream," bad actors can infect a single component, which will then be distributed “downstream” using legitimate software workflows and update mechanisms.
Next-generation cyber attacks actively targeting open source software projects have increased 430% year-over-year. From February 2015 to June 2019, 216 such attacks were recorded. Then from July 2019 to May 2020 an additional 929 attacks were documented.
Next-generation software supply chain attacks are possible for three reasons:
Open source projects rely on contributions from thousands of volunteer developers, and discriminating between community members with good or malicious intent is difficult, if not impossible.
Open source projects themselves typically incorporate hundreds — if not thousands — of dependencies from other open source projects, many of which contain known vulnerabilities. While some open source projects demonstrate exemplary hygiene as measured by mean time to remediate (MTTR) and mean time to update (MTTU), many others do not. The sheer volume of open source and massive number of dependencies makes it difficult to quickly evaluate the quality and security of every new version of a dependency.
The ethos of open source is built on “shared trust” between a global community of individuals, which creates a fertile environment whereby bad actors can prey upon good people with surprising ease.
When malicious code is deliberately and secretly injected upstream into open source projects, it is highly likely that no one knows the malware is there, except for the person that planted it. This approach allows adversaries to surreptitiously “set traps” upstream, and then carry out attacks downstream once the vulnerability has moved through the supply chain and into the wild.
A constant refrain among leaders in development is that while there are innumerable candidates for any given job, finding someone with the right skills is often impossible. Developers blame HR for recruiting the wrong candidates. New recruits are difficult to ramp up to productivity and many don't work out at all. The recruiting and hiring cycle lengthens and no one is happy.
The problem, however, is not with individual recruitment pools, HR policies, or company geography. The real problem is with an ecosystem for training developers that is broken on every level.
With everything from University programs producing degreed computer scientists to boot camps graduating "full-stack" developers within weeks, one might think that filling developers' roles was easy-- But the plethora of contemporary training opportunities have only added complexity and noise to the milieu.
In this session, award-winning online instructor Mark Lassoff, will discuss the problems endemic in developer training and make suggestions that any company can implement to start fixing the problems. Lassoff has taught over 1.5 million developers online and thoroughly understand the upsides and limitations of the current training models.
After this session, you will be better equipped to recruit, onboard, and retain entry-level developers. You will also be better positioned to advocate for industry-level change so that there is a better match between those completing training and the opportunities awaiting them.
You know you need top talent. But recruiters have annoyed you for years. Or they've done the heavy lifting and now that you're looking to build your own team - you're stuck. This session will show you how to set a talent strategy, look beyond your network and engage directly with the people you want on your team.Attendees will leave with tools, templates and a new deeper understanding of talent acquisition. This will be a spam free session! It doesn't work and everyone hates it!
The process of hiring has always been simple: candidates apply, they are interviewed, sometimes given a task or test to complete, then they are hired. But what if the future of hiring was still simple, but used complex AI to find the perfect candidate? Vivek Ravisankar, Co-Founder & CEO of HackerRank, says AI in hiring is now becoming essential, but that’s not all. In order to scale your teams successfully, companies need to start utilizing new hiring tools, but they also must be using those tools correctly. Right now, we need to rethink AI’s current and future role in hiring, so Vivek will dive deeper into the benefits and challenges of using AI while recruiting and how AI will play an important role in sourcing and hiring as we move forward in an increasingly digital world where face-to-face options aren’t readily available anymore.
As engineering leaders, we have the responsibility to translate our engineering activities into business outcomes--from providing value to customers to driving profitability. It’s also important to have a growth mindset, looking for areas of improvement whenever possible and coaching teams to do their best work.
There’s no doubt that creating, tracking, and reporting on engineering KPIs is important, for both the engineering team and company as a whole. However, tracking the right metrics, establishing outcome-based KPIs, and wrangling data from disparate sources can be a challenge for many. This talk offers practical solutions to overcome these challenges and drive continuous improvement.
Tracking engineering metrics allows you to have meaningful conversations with your teams and peers around improving efficient engineering processes, view patterns in work behavior, advocate for more resources when needed, and get the most value out of your team. Objective data also helps you spot common issues and alerts you of when individuals or teams need coaching or guidance.
Engineering and product leaders have historically collected and tracked activity on 5+ tools to manually analyze data and create home-grown reports for daily operations. Learn how you can use a platform, like Allstacks, that uses machine learning and ai to make software delivery more predictable and offers a single source of truth for everyone to stay aligned.
How to develop and track the right engineering metrics and ensure they directly support overarching company goals
How to create a single source of truth, benchmark efforts, and keep everyone aligned to work towards the highest level priorities
How to use data to advocate for engineering needs, coach individuals and teams, and manage internal and external stakeholder expectations
What steps do you take in creating a diverse and Inclusive High-Performance Engineering Organization? High-performing engineering teams don't just happen. It takes conscious effort. They need these essential elements - Vision, Values, Build trust via Psychological safety: In high performing teams, Engineers share their opinions without fear of negative consequences of self-image, and being judged. Structure and clarity: On high performing teams, each individual understands their job’s expectations, the process for fulfilling those expectations, and the consequences of their performance. Meaning and impact: High performing teams have a sense of purpose in either the work itself or the output is important for team effectiveness.Team autonomy and Effective collaboration is the secret to success of building world-class engineering teams. How do you motivate your engineering teams by creating a culture of celebrating success? We'll get to hear directly from experienced engineering leaders on these critical culture topics.
Friday, February 19, 2021
When starting to build your team, what are you looking for in a candidate? Technical skills? Leadership skills? Ability to get things done? Over the past decade, I have built and managed many engineering teams, and when I looked back on my 10x developers and looked at what differentiates them from the others, I noticed that it wasn't necessarily superb technical skills or years of experience, but rather their sense of ownership.
In this talk, first, I will convince you why ownership is so essential to your engineering culture. I will explain why, if you own something, it makes you care a bit more about it. Why once you feel accountable for your deliveries and your domain will welcome responsibility gladly. And why ownership might starts with your territory and field but tend to grow and to increase your influence globally, not just locally.
Having people that care about the value they bring to your team, to the entire R&D, and your company’s goals are so fundamental, I believe it is one of the critical building blocks for creating a healthy and prosperous engineering culture. So, I will share how to look for a sense of ownership in a candidate. What kinds of questions you should ask in an interview to spot it, and how to make the right recruiting choices. And will share some tips and tricks, how to define and measure ownership in your existing team members, how to encourage them to take more responsibility for themselves, and why this is important - not just for the company's sake but also for their own.
Building a team of individuals with a sense of ownership who can work together will genuinely make the whole more significant than the sum of its parts and will maximize your team's full potential.
Breaking changes are sad. We’ve all been there; someone else changes their API in a way you weren’t expecting, and now you have a live-ops incident you need to fix urgently to get your software working again. Of course, many of us are on the other side too: we build APIs that other people’s software relies on.
This talk will cover how you can:
(a) Get really good at identifying what changes *might* break someone’s integration
(b) Help your API consumers to build integrations that are resilient to these kinds of changes
(c) Release potentially breaking changes as safely as possible
Companies have long relied upon static analysis to secure their code, but the typical process with delayed results and high false positive rates is painful for developers and generates unnecessary work for security engineers. A recent trend is changing that. Code analysis tools are increasingly delivering better developer experiences, coverage of a broader set of bugs, and improving results over time. These improvements allow a much tighter integration into modern agile development processes, shifting left the detection of reliability and security issues. Google and Facebook have pioneered this new model of static analysis that involves broad deployment of extremely scalable analysis tools (billions of lines of code / thousands of commits per day) and have collected and published extensive data on its impact on code quality. Amazon has also used static analysis to streamline certification and compliance tasks. With development teams more distributed than ever, tools like static analysis become increasingly critical for development organizations to overcome the loss of productivity and risk to code quality.
We all know that out-of-the-box thinking is a highly valued competence that is deeply sought in all fields -- including engineering -- to attain exponential growth. But it also is truly exhausting to be different from others at the table, so why not just comply? Learn about tools to identify, self-examine, strategize, and break the mold leading yourself to new horizons and own your success.
The intention of this conversation is to raise some relevant questions about the relationship with the developers. Do companies need this? Is important? Is there a real impact when promoting an incentive program for developers?
Today, product development teams are more global and diverse. Working with different cultures brings benefits of different points of view and perspectives. Research has found that diverse teams are more innovative. However without the right framework can become dysfunctional. Organizations are becoming more intentional on building a global mindset in product development by building diverse teams. In this talk, we will review the benefits of diversity, how to create a global mindset in teams and building a culturally competent organization.
The one question I'm asked more than any other when talking about working at GitLab is: wait, you don't have any offices? That is often followed by a confused look or the direct question: How?
Writing down decisions, asynchronous communication, measuring results, not hours. Companies often aspire to these goals...however in an all-remote company, they aren't aspirational - they are requirements. GitLab has grown from 9 people in 2014 to over 900 people in 55 different countries with a valuation of almost $3 billion.
In this talk, we'll discover some of the not-so-secret sauce that GitLab has leveraged to achieve this growth. On this journey, our values have remained the same. We value collaboration, results, efficiency, diversity & inclusion, iteration, and transparency. And we've done all that without having any office, headquarters, or anything that looks like one.
PRO SESSION: The Persuasion Equation - How to Effectively Communicate Results to People Who Don’t Want to Listen
This session will present a winning workflow for Analysts, Developers and Engineers to harness the power of persuasion with data. Attendees will hear how to present the results of their data science, projects or analysis and drive their audience to act on those results.
My experience with presenting my work in data science to people who then became inspired to act on that work, when they initially didn’t want to listen. I call this “The Persuasion Equation”. It's how I found a way to make my voice heard within an organisation, and it’s the difference between insights and action.