MunderstandMe

DeveloperWeek 2022 Overview (SF and virtual)

Written on: February 19, 2022

Pre-Conference

  • Received a lot of marketing materials before the conference, seemed like a job fair with different booths from companies. Email communication was a bit much but was able to un-sub and find my way around fairly easily.

  • The conference dashboard busy at first but actually worked pretty well once I got used to navigating it. Overall only a few technical hiccups, some presenters could have used more time for Q&A but it was a packed schedule. Lots of 30min talks which were an exercise in stamina to focus on for a whole day.

  • There was a gamification aspect to the conference. Collecting codes at different talks would get you prizes/giftcards at the end; also a few raffles going on: AirPods, Oculus, NintendoSwitch.

  • Three tracks: Developer, Cloud, Product

Takeaways

  • For a free conference, definitely would recommend attending. Lots of really intelligent presenters with a variety of topics. Could use more time for certain talks to help prevent too much context switching for attendees.

Resources


Day 1 Tuesday 02/08/22

Why Every Developer Should Know Basic Javascript by David Aquinaga (Encora Inc)

  • The first programming language doesn't matter but more so the logical reasoning and the programming paradigm. The rest will happen as you immerse yourself in the industry.

  • JS is a living language: it receives updates, has strong community support and a roadmap.

  • Created by Netscape Communications in 10 days in 1995.

  • JS is the most popular language. Even backend developers are choosing it more often now. It's become the go to language for many companies which allows devs to only worry about a single language. Easier to debug, saves costs, etc.

  • Since JS runs in the browser we can run it almost anywhere. This means it's a valuable skill to know since it allows you to create websites/apps in different environments.

  • JS also exists outside of the internet. You can build cross-platform desktop/native apps, works with IoT (internet of things)

  • Because JS is on a large variety of platforms and makes it easy to turn details into abstract concepts it's ideal for newbies AND professionals.

  • Career potential of knowing JS is growing, increasing demand for JS.

  • JS is only secure to the degree that you make it secure. There are a lot of protections within the language itself.

TAKEAWAYS:

  • Good intro to the conference, good for newish JS devs as a primer.

  • Speaker had a good cadence and was easy to listen to.


Security is Everybody's Job by Tanya Janca (WeHackPurple)

  • Application security is any and every activity you do to make sure your software is secure.

    • It can be both formal (pentests) or informal (dev feedback)

  • Poor security in software causes 29-40% of data breaches.

    • APIs and WebApps are #1 and #2.

  • AppSec is missing from the education curriculum, typically not covered in Comp-Sci and Soft-Eng programs.

  • Security is outnumbered, GitHub released a report that shows company structure is typically 500 devs for 100 ops for 1 sec.

  • Waterfall projects failed 70% of the time

  • We need DevSecOps which is is app sec in a dev ops environment.

    • Goal is to have apps which are created to be secure.
    • Could look like data scanning tools in the pipeline.

  • The three ways of DevOps:

    • Emphasize efficiency of entire system.

      • DevOps should lower failure rates - resiliency - better availability

    • Get fast feedback that is accurate.

      • DevOps should improve deployment frequency - fix bugs faster

    • Continuous learning such as taking risks, doing experiments and taking the time to improve.

      • DevOps should have faster time to market - security doesn't win if business doesn't win

  • You can help app sec teams fine tune their tools by giving feedback.

  • Consider negative tests along with positive tests. Negative tests are handling invalid states gracefully.

  • Fixing bugs earlier in the process is cost efficient. Spotting bugs on production is costlier than spotting them in tests.

  • Consider doing security sprints where the focus is solely on bashing security bugs, upgrading vulnerable packages, etc.

  • Treat every security issue as a learning opportunity.

  • When you find a solution to something, share the information widely.

  • Perform blameless postmortems. The issue is never due to a human but rather the process.

  • Security is meshing with dev culture and we should lean into it.

    • Celebrate your security wins.

    • Work more closely (devs + security + ops).

    • No blaming individuals, look at the processes.

    • Become a security advocate (learn, volunteer, share).

TAKEAWAYS:

  • Seemed like a devops professional guiding non-sec devs on improving their feedback. Lots of good practical advice.

  • Concepts were centered around improving communications between Devs and DevOps.

  • Speaker was personable and friendly, easy to follow, seemed like they really enjoy what they do.


5 Principles for Creating Stupidly Brilliant JS Apps (or how to write stupid code) Mike Manwill (Smarty)

  • There are complex concepts all around our universe but the underlying laws are fairly simple.

    • Life is really simple but we insist on making it complicated - Confucious

  • Why is smart code dumb?

    • Difficult to read and understand.

    • Bug prone and hard to debug.

    • Hard to maintain and extend.

    • Requires frequent refactoring and has a short lifespan.

  • What are symptoms of smart code?

    • Functions take in a lot of parameters.

      • Merging params into a config is not the solution.

    • Lots of conditional logic

      • if statements, ternaries, logical operators, etc.

    • Lots of comments in the code.

      • You need comments to explain what it does because it's too complicated.

    • Brittle code.

      • Do you have a lot of edge cases? Scenarios which are hard to get just right? constantly breaking tests? Is the code difficult to follow? Hard to get back into the groove after a break?

  • Five principles of stupid code (there are more but these are common ones):

    • Take the time to really understand the problem. Don't jump into the code.

    • Decouple different ideas (separation of concerns).

      • UI, data, styles, 3rd party services, business logic, etc.

    • Pass the thing instead of the parts to build the thing. Don't pass components to build an image, pass the image itself.

    • Refactor

      • Your code should go through multiple drafts and get feedback from others.

      • Be conscious of business needs, flawless code pays off down the road but not right away

      • If it works, deploy and refactor later. Aim for better instead of perfect.

      • Distinguish between important and unimportant refactors.

    • TDD

      • Write a failing test, write enough code to pass it, refactor, rinse and repeat.

      • TDD forces you to enforce the first four principles.

  • How to dumb down smart code:

    • Don't do it all at once.
    • Start with low hanging fruit.
    • Follow the Up.In.Out principle

      • Lift complexity Up to parent functions.

      • Restructure complexity In the parent.

      • Move functionality Out to appropriate location.

TAKEAWAYS:

  • Presenter read off the slides a lot but was personable and funny. Made it easy to follow the talk.

  • Some of the portions of the talk seemed overly complicated, didn't need to go into so much detail around specific problems.

  • Learned about the Up.In.Out principle explanation for starting refactors.

  • Overall good presentation which highlights core concepts of clean programming paradigms.


Move Fast and Don’t Break Things: Security at Scale by Merrit Baer (AWS principal)

  • If you had limitless access to data, what problem would you solve? How would you behave differently?

  • The shared responsibility model:

    • Security in the cloud means the customer is responsible.

    • Security of the cloud means AWS responsible.

  • Engineering teams at Amazon are intentionally siloed. It's a security strategy in itself.

  • AWS Nitro System provides live updates with no downtime. Something you benefit from but don't even know it. Doesn't have a human toggle for access.

  • Merrit's North Star Principles:

    • Minimize human access

    • Automate

    • Encrypt

    • Build tools

    • Practice Incident response

    • Pay attention to metrics

    • Push don't pull

  • 2002 Bezos API mandate was to expose all team data through APIs. No direct linking, shared models, etc. All services must be able to be interacted with via the network using any tools.

  • Governance, Guardrails and Democratization:

    • Metrics and accountability. Controls change management over time.

    • Prescribing access and actions, paved roads.

    • Ability to delegate ownership down to developers and stakeholders.

  • 100% of execs will say they care about security, how do we change visibility so that there is accountability?

  • Embrace immutability

    • Visibility, configuration drift, reversion to known good state

  • Encode your policies as logical formulas.

  • Every team owns the security of their own service. CI/CD at scale.

  • Moving forward, expanding and changing is cheaper than staying as is.

TAKEAWAYS:

  • Seems like a smart individual that has a very comprehensive view of security, data, big business, etc.

  • Parts of the talk seemed a bit preachy regarding AWS and Amazon principles...ideal in principle but vague in practice.

  • Not a lot of day to day advice but good talk about general principles of security. Advice for planning culture changes rather than individual project changes; company philosophy.


Merge PRs in Half the Time by Dan Lines (LinearB)

  • From LinearB data: the average software dev cycle is 6 days, 4 hours.

    • 4 days are spent in code reviews.

    • Code and deploy times are shrinking.

  • Most PRs sit idle for ~50% of their lifespan

  • Transition (idle) time hurts dev productivity via context switching, increase in cognitive load, etc.

  • All PRs are not equal in severity but they look like it at first glance.

  • Distractions hurt PR productivity. Need to re-read comments, re-read code, etc.

  • Idea #1: keep your PR under 200 changes.

    • PRs with 600+ changes take 2x as long to merge than ones with <200 changes

    • LinearB team data science team analyzed 735K PRs to gather this data

  • Idea #2: Add context to your PR.

    • Tag relevant reviewers, add related issue link, identify risk areas, estimated review time, real time alerting for reviewers, include test coverage % and context.

  • Idea #3: Finish important PRs in one day.

    • PRs which are open for more than one day are idle for ~80% of their lifespan

    • Open PRs in the morning, find a reviewer within the hour, make changes right after comments are left.

  • Idea #4: Go synchronous for PR reviews

    • Start a pairing session, schedule a time, respond fast to questions.

  • Idea #5: Discuss review time in the retro

    • Long living PRs are correlated with longer cycle time, high code churn, unplanned work, low planning accuracy.

  • How LinearB can help (SaaS product, linearb.io):

    • Track progress of PRs visually.

    • WorkerB app for Slack provides review time estimates, automates tasks, cuts the noise.

    • WorkerB personal Chrome extension is free. Provides estimated review time, notifies you when reviewer is viewing the PR.

TAKEAWAYS:

  • Intro of the talk was a bit too repetitive IMO, could have moved a bit quicker to the meat of the presentation which was more relevant.

  • Topic is really interesting and data can be useful both at scale and on individual level.

  • Toward the end of the talk it was a bit sales-y but seems like an interesting tool to try to improve PR review velocity and identify pain points. There were a lot of things mentioned which we already do.


A Modern Approach to Better Agile Planning by Devin Stoker (ClickUp)

  • Agile adoption across dev teams increased from 37% in 2020 to 86% in 2021

  • No one does agile the same, tool flexibility is necessary.

  • You need to have:

    • Easy to use interface.

    • Template and automation features.

    • Easy way to provide high-level project views.

    • Email becomes obsolete in favor of tool notifications.

TAKEAWAYS:

  • Got realllll sales-y at some points but they have a free tier so eh.

  • Large part of the presentation was a demo of ClickUp tool...not super interesting unless you're struggling for Agile management solution.

Breaking the Monolith: A Case Study in Starting Over by Brad Powers (Passport)

  • His company built a product which moved parking enforcement to the web/mobile payments.

  • Every city added complexity to the initial system that was built. That system was not built to scale and allow for configuration options to that degree.

  • Parking enforcement issues have a lot of down stream effects on a city (revenue from them is huge). Problems with the system mean people lose their cars/licenses, courts can't send collection notices in time, etc.

  • The digital Enforcement involved monitoring/issuance, lifecycle management (which agency does it go to outside of parking enforcement) and notification/resolution.

  • When speed is favored over scalability you get a monolith app

    • Continuing to build on existing system started to weigh on the system.

  • The original app was a mix of good and bad decisions.

  • A workflow tool during the build would have been useful but the team was small and fast.

  • The more cities used it the more complex it became. Each city had a different solution so allowing many permutations of the configuration were necessary.

  • Tech debt, maintenance and regression testing became really hard to do.

  • Building V2 involved supporting rapid delivery, aggressive growth and scalability, building client trust, managing tech cost of ownership, consolidating first and third part data in centralized repo.

  • Lessons learned: Which features aren't used? Which tools need to be more flexible? What needs to be configurable? Where do devs spend their time? * Where do customers spend their time?

  • Built a UI-first model to show value to customers quickly, gave additional good will to rebuild as necessary. This in turn gave time the API to be built out as needed.

  • Moving the micro-services to AWS allowed them to keep and attract devs, specifically full stack devs. Their new prod target state architecture is a pattern which can be replicated.

  • V2 is as configurable and flexible as possible. The cities can get 90% of their asks now and the team is finishing up the rest.

  • V2 has provided a better experience for street officers, back office staff, 3rd party integrations, API integrations and the devs.

  • Cities now get paid faster. Systems which were 20-30 years old are being replaced.

  • Best practices: Build for scalability but don't over-architect. Architect with the happiness of your current and future developers in mind.

TAKEAWAYS:

  • Talk was like a story, easy to listen to. A bit high level but some concepts which can be translated to every day work and mindset.

  • Fascinating to find out a bit more behind the scenes of how mobile parking systems evolved.

  • Speaker is easy to listen to and didn't read from the slides.


The Changing Art of Debugging by Nick Hodges (Rollbar)

  • Debugging means time. Debugging is like treasure hunting and you want to have a map. Tools like Rollbar can be that map.

  • When hunting bugs you want your fix to be small and your hunt to be short

  • Most of the talk covered advice on shortening the hunt time.

  • With SaaS/Cloud/Native debugging is "out there" so you have observe

    • Can't repro prod on local machine.

    • Can't debug on your server.

    • Sometimes 3rd party services are out of your control.

  • Observability is not enough, we need intelligence behind it.

    • Tools like Rollbar can help with grouping bugs, removing noise to focus on the signal.

    • Tools can leverage ML and automate response workflows.

    • What you want is ML powered bug grouping.

TAKEAWAYS:

  • Kind of a quirky presentation but easy to listen to.

  • Turned a bit sales-y halfway through but tool seems worth trying out.


The Productive Developer by Niaja Farve (CNN)

  • A productive dev is one who contributes well written code efficiently, helps the team, learns continuously and completes their career goals.

  • Starting the day strong

    • Time Blocking can be helpful. Block off focused times to engage your tasks without distractions.

      • This could mean muting notifications, offering office hours, using Slack status to indicate availability, staggering the workday/lunch to prevent being available during main work hours.

    • At max, pick 3 tasks to complete: can be a mix of personal or professional, should be able to completed in the day.

      • Start with the hardest task.

      • At the end of the day you can re-prioritize your tasks.

  • Make time for "building up the team" (*great phrase) by reviewing PRs, making sure you're available to help others.

  • Make time for growth. A steep learning curve can be mitigated by using the language/tool for a day without any boundaries.

    • Pick a tech/concept/question and learn what you can about it at a high level view. Reading documentation can help with this.

  • Make time for your career goals.

    • Have clarity on next steps to get you to the next level.

    • Participate in skill development opportunities.

    • Offer to offload tasks from individuals you look up to.

    • Become an expert in a domain.

  • Journaling:

    • Recommended reading: "Journaling as a Developer" by Brittney Braxton

    • Tracking your day to show progress on larger tasks.

    • Tracking your achievements and having a list of wins.

    • Notes about conversations, learnings, etc.

  • Reflection:

    • Daily:

      • What did you work on?

      • What went well?

      • What are you doing next?

    • Weekly

      • What progress did you make on your goals?

      • What are your goals for next week?

    • Quarterly

      • What new goal can you set for next quarter?

      • What learnings can you integrate into the next quarter?

      • How does your progress affect your end of the year goals?

  • Goal setting:

    • Transfer yearly goals into quarterly goals

    • Make progress on a cadence similar to the business

    • Incorporate your PTO into the quarter

    • SMART goals

      • Specific, Measurable, Achievable, Realistic, Timely

  • Be effective with your time.

  • Know when to go for a walk.

  • Stick to your time restrictions.

  • Use the Pomodoro technique.

TAKEAWAYS:

  • Seems like a very accomplished person. Currently building CMS system for CNN which is pretty wild to think about (scale and complexity). Hoped she would talk about her experience building it but didn't get a chance as Q&A got cut short. Her chat was lagging behind by 30sec so a bit hard to communicate.

  • The talk got increasingly more useful over the length of it.

  • Seems like a useful talk for newer devs, especially in regards to actionable advice with things you are struggling with. Lots of topics and strategies covered.


Building a Ship While is Sails...During a Pandemic by Cem Yildirim (Fast)

  • The organization was built from the outside (virtually) due to the pandemic

  • Spending more time on architecture initially allowed them to keep the same underlying tools even though product changed

    • A model that allowed relations, allowed for no migrations later

  • Pandemic ended up ballooning fintech (finance tech) and new ways to improve product showed themselves

    • Explosive growth meant explosive competition. You can't be perfect in every way

    • Building features slows down main product roadmaps

      • Fast allowed companies an integration experience that allowed them to worry about other things they're better at

  • To make it fast:

    • Build a small ship and ship it often

    • World class infrastructure

    • Strong collaboration

    • System transparency

    • Robust preventative change controls (postmortems)

  • Structure the org for optimum collaboration, management and conflict resolution during tight release schedules

  • The Fast team worked together for two years before meeting in person. This meant that they needed really tight onboarding processes

TAKEAWAYS:

  • Didn't really strike a note with me but interesting story around how a large company handled product launching right in the middle of the pandemic

Wrangling Configuration Complexity: How It's Gotten Even Harder by Chip Childers (Puppet)

  • Technological complexity is reaching the limitations of human comprehension

  • Jevons Paradox

    • In economics, the Jevons paradox occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand.
    • If it's more efficient, more people will use it, not giving any benefits
    • The efficiency dilemma

  • Efficiencies in IT

    • Efficiency of access (APIs)

    • Efficiency of cost (per-MB cost)

    • Efficiency of scale (tech advances)

  • Infrastructure spending keeps growing (Jevons Paradox)

    • All cloud spending estimate for 2025 is $1.3T

  • Established companies these days have layers of complex, interdependent systems

    • Complexity grows every year and the business ends up needing more tech

  • Cloud and Cloud Native was supposed to make things easier

    • Growth is outpacing the ability to manage it

  • Things are more complex, not less

    • Tools in isolation are better but new tools are being built faster than old ones are decommissioned

  • Puppet was based on infrastructure-as-code

  • Infrastructure best practices can be re-used

  • Possibility for human errors moved to design-time

  • Managing infra complexity at human level

    • Cognitive load theory: the amount of our working memory used at any one point in time

      • Intrinsic: overall complexity of new info being processed

      • Extraneous: sources of working memory usage that are distractions from learning the goal (twitter and such)

      • Germane: The brain process of integrating new info into existing knowledge

  • Working memory model

    • Aspects of coding can apply to this model

  • Program Comprehension and Code Complexity Metrics

    • Finding ways to measure for code complexity

  • Reducing Cognitive load:

    • Prefer declarative style to declare cognitive load

    • Naming matters, intrinsic naming helps reduce phonological loop in your brain

    • Well structured modularity reduces the need to keep a large mental model

  • Organizational management of complexity

    • Org design should match your system design

    • Teams benefit from reduced complexity through limited scope

  • Limit the number of tools

    • API based contracts between teams

    • Clear contract between layers, allows you to focus on a piece of the puzzle

    • Manage at the module level

  • In the end, humans have been here before and overcome the problem

TAKEAWAYS:

  • Presenter seems to have a very wide world view and over 25 years of experience in tech and managing tech complexity

  • Interesting topic and presenter was easy to pay attention to, there was a straight line of thought

  • Would be good to rewatch to pay attention to the slides a bit more. Lots of good theoretical info around managing complexity

  • Random tool shared in chat: https://www.openstenoproject.org/plover/


The 10,000 Steps of Open Source Project Health by Dmitry Vinnik (Facebook)

  • Goals:

    • Determine the quality of the OSS

    • Provide guidance for OSS

    • Show communication as a priority

  • Are there metrics that can define OS health. Short answer, no. Long answer, depends.

    • There are some metrics but they're weak (stars, issues, SO posts)

  • Five things to consider when thinking about OS-ing

    • Planning

      • Why to open source a project?

      • Is your team passionate about it?

      • Think long term when deciding to OS

    • Branding

      • Name, logo, narrative,

    • Documentation

      • A cornerstone of OS, makes or breaks the project

      • Great for contributions

    • Codebase

      • code of conduct, rules for community

      • README

      • Contributors guide

      • PRs and issues

    • Community Work

      • Team driven

      • Focus on content

      • Create a community space

      • Communicate, it's hard to overdo it

TAKEAWAYS:

  • Fast talker but covers topics in a good way, doesn't just read from slides

  • Good primer to open source


Day 2 02/09/22

How to Make Product and Engineering Work Together Effectively by David Subar (Interna)

  • Five things you need to overcome culture clash:

    • Alignment

      • Optimize the team

      • Making efficiency the only goal puts up barriers to building the product

      • Create a bond between product and engineering

      • Customer value. Produced by creating excessive value at reasonable expense

    • Measurement

      • Which metrics to report?

      • Engineering and Management have different vocabulary

      • A lot of metrics report efficiency but not customer value

      • Epic statements are a tool that speak to outcomes not outputs

      • We believe that if we {do this thing} for {this group} they will achieve {an outcome} and we will know it's true when {this metric is achieved}

    • Review

    • Transparency

    • Iteration

TAKEAWAYS:

  • A bit slow and product oriented so not super relevant to dev interests

  • Content was philosophy around management


Introduction to AI by Camilo Rodriguez (Ia Mon Dada)

  • AI logic is built up step by step

  • Classical software developer follows the steps:

    • Use data -> write logic -> produce some results

  • Machine learning follows these steps:

    • Use data -> write logic -> introduce new data -> produce some results

  • Data collection and model training are big parts of improving AI

    • ML is never perfect but it's always improving

  • Resource: https://teachablemachine.withgoogle.com/

  • ML has been used to detect different types of skin cancer

  • Number recognition was one of the first things to test ML

  • Defining AI is very difficult, intelligence alone is hard to define

    • AI could be defined as software that mimics intelligence

    • ML is software that uses math and statistics on data

TAKEAWAYS:

  • Talk was more of a story and low level explanation of how AI interprets data and translates it to humans

  • Speaker was engaging and easy to follow

  • Very much a hot dog/not hot dog presentation and intro to ML


What We Learned about Hiring Engineers after 6,000 Technical Interviews in One Year by Michael Stahnke (CircleCI)

  • Getting a good signal for whether a hire worked out is very hard

  • Experts can be hard to interview because you need an expert to know whether they're good at what they do

  • Every engineer at CircleCI was required to train for interviews

    • This included bias recognition, philosophy of interviewing and acknowledging a stressful situation

  • One of the experiments they ran was to shorten the interview process

    • It was taking days to get through their existing process which mean week long schedules
    • The result was that candidates moved faster but consistent results were still a challenge

  • Other issues that remained were consistent grading of take home exercises, same interviewers having heavy rotations, bias still existed

  • A possible solution was to source technical interviewing to specialist (karat)

  • Another experiment was to move technical screening to a 3rd party

    • Interview was still mostly on site but the technical part was outsourced

    • This helped reduce scheduling load, consistent review of skills, ability to re-do interviews at candidate discretion

    • Some concerns were moving process out of company that the candidate was interviewing for, unable to sell the company during interview, confirming diversity of candidate pool

  • Lesson learned from 3rd party were that scaling interviewing is difficult even if you specialize in it

  • There were issues with outsourcing to a 3rd party:

    • Candidates had to go back and forth

    • Couldn't easily modify questions

    • Had to watch interviews to confirm assessment

    • Some candidates dropped out due to use of 3rd party

  • The next experiment was to move technical screening to pair programming interview

    • There were more "this is the job" questions

    • Bigger degree of control over questions

    • Candidate had better access from actual CircleCI engineers

    • Some engineers still took heavy brunt of interviewing

  • Did more engineers equate to more output. Yes

  • The candidate feedback of the interview process was better with improvements

TAKEAWAYS:

  • Speaker was good presenter and made it easy to follow the topic

  • The topic had interesting topics for both interviewees and interviewers but not too many day to day takeaways


Developing the Modern Web with Jamstack by Matt Billman (Netlify)

  • A web has two main parts, UX and DX

    • A story of performance (UX) and a story of productivity (DX)

  • UX challenges involve talking to many APIs without performance loss

  • DX challenges involve integrating all services into viable workflow. Make it feel like you're developing one application

  • Solving for performance

    • We take global edge deployment for granted now

    • Things like pre-rendering, edge logic and serverless functions are expanding

    • Today there is a large web framework landscape

    • There are two main pathways diverging, pre-rendering all content and server rendered content

  • Solving for productivity

    • How do we manage complexity and organize all of the APIs to feel like a single workflow

    • GraphQL is emerging as a leader for a lot of companies

    • The traditional REST API approach has a lot of steps

    • Netlify is moving to simplify this approach via simple click to install processes

TAKEAWAYS:

  • Pretty cool to hear from the CEO of Netlify

  • Topic was relevant to my day to day interests so I found it very relevant but if one didn't have experience with Netlify, might not be so easy to follow the demo portion

  • Demo showed a good example of how Netlify is simplifying hooking up to other services


Burnout and Productivity: Overcoming Emerging Engineering Team Difficulties by Ravs Kaur (Uplevel)

  • Definition

    • A syndrome resulting from chronic workplace stress that has not been successfully managed

    • Exhaustion, Cynicism, Inefficacy

  • Causes

    • Love deep work. Devs love to be builders and todays dev environment is different

    • Frequent interruptions

    • Too many meetings

    • Mis-alignment between skills and career goals

    • Pandemic making everything worse

  • What to do

    • Detachment, Relaxation, Mastery

    • Experimenting and trying different things can help, prioritize yourself

    • Find things that energize you

    • Talk to someone you trust about it, check in with your manager

    • Review your current priorities

    • Do you need to load balance, are you context switching too much, do you have varied work

  • Data you can use

    • Understand what it is and if you're feeling it

    • Identify the stage you're in

    • Prioritize yourself

    • You're not alone, ask for help

TAKEAWAYS:

  • Presenter was easy to follow and slide deck was interesting

  • Lots of attendees identified with this talk in the chat

  • Good topic which affects all of us but isn't necessarily brought up


Embracing Open Talent by Dan Reitz (Top Coder)

  • Open talent is the crowd of global talent available outside of internal hires

  • Business areas with greatest need to address potential skill gaps:

    • Data analytics

    • IT, mobile, web design/management

  • Talent and employers now seek each other out on more equal terms, from anywhere in the world

  • Businesses are flocking to improved access to highly skilled talent

  • NASA Tournament Lab embraces open talent which shows government is not averse to open talent

  • Has set up a network of 40+ open innovation firms and communities

  • As a freelance dev:

    • join a community, create relationships, build the network

    • Digital profile, showcase your skills, package yourself

    • Access to brands and companies looking for freelance talent

  • As a business looking:

    • Access to wider network of experts

    • Scale up or down based on your projects

    • Reduced development time

TAKEAWAYS:

  • Interesting topic especially as it relates to the pandemic and some of the staffing shortages being reported in the IT sector

  • Good resources and recommendations for those looking to freelance


Rapid Evolution of the Canonical Stack for ML by Daniel Jeffries (Pachyderm)

  • We have a Cambrian explosion of companies building massive array of ML software, democratizing AI for the rest of us

  • It's still really complex to understand how all of these parts interplay

  • The ML maturity journey:

    • Exploratory stage

      • disparate teams, no automation, slow releases, first model

    • Production stage

      • Build out MLOps, automate workflows, add versioning and testing

    • Scale stage

      • Cross team sharing, full automation, high release velocity, robust and reusable tools

  • The ML lifecycle

    • Prepare data

    • Experiment and develop

    • Train the model

    • Deploy

  • Most of the time in the flow is spent on the data and training stage

    • This is the unsexy, pipeline plumbing stuff

  • The data science orchestration is more focused on experimentation and confirmation

    • Uses the prepared data from the previous step

  • We're going to see different pieces of technology being used together to form a whole stack

    • He doesn't see a situation like WMWare where one company "won"

    • Each situation is different and each company needs a different solutions

  • ML security is still missing completely. Sophisticated security systems for other software are not present in ML

    • Solutions will be provided by security companies once the problems are better identified

  • Anomaly detection and observability is still not where it needs to be

  • A generic model for ML is starting to emerge

    • Abstract factory for ML would be ideal (like kubernetes)

TAKEAWAYS:

  • Interesting background around ML at enterprise level and the lay of the land as to how complex ML systems work

  • Would be interesting to rewatch and pay closer attention to the pipeline slides

  • Speaker was well spoken and easy to understand. Comprehensive answers to chat questions.


Demystifying NFTs by Tejas Chopra (Netflix)

  • NFTs have exploded recently

  • Non-fungible tokens are defined by unique properties which represent ownership of items. They only have one official owner at a time and are secured by blockchain.

  • The internet of assets is turning everything into the digital realm. They only work in the context of their product (points)

    • By using NFTs artists can sell their work outside of the context of the product

  • NFTs have unique properties

    • Each one has a unique ID

    • Not interchangeable with other tokens

    • Each token has an owner and is easily verifiable

  • Scarcity is determined by the creator which maximizes earnings for the creator

  • NFTs allow for royalties for individuals which isn't currently manageable

  • Examples of NFTs:

    • Digital artwork

    • In-game items

    • Tweets

    • Essays

  • NFTs in gaming can provide records of ownership in-game

    • Developers can earn royalties each time an asset is traded

    • Assets can outlive the game and be used in other games as well

  • Unique NFTs

    • Virtual land

    • Sports

    • Insurance policies

    • Virtual names in games/projects

  • NFTs can be minted by different blockchains

  • There are concerns around NFTs not being environmentally friendly due to the computing power used

  • However, they are more efficient than what we have currently

  • He thinks NFTs will live alongside with de-centralized finance

    • DeFi will allow you to borrow money against NFT

  • He thinks you will be able to buy fractional NFTs

  • He thinks NFTs will start being related to even more assets

    • cars, houses, open source software all on the blockchain

  • NFTs are very new so governments are still trying to figure out how to treat them

  • NFTs will start being used in patenting and patent office will use blockchain as a backend

  • Value of NFTs is better when it can be backed by a physical asset. Most of the current NFTs are just about hype

TAKEAWAYS:

  • Interesting topic covered at a very high level. Included a demo on how to create and purchase NFTs

  • The presenter was easy to listen to and follow

  • Interesting questions around patents and the blockchain


Back to BlogScroll to top