Pains and Gains of being a Full Stack Developer
As the industry is shifting towards an Agile (Continuous Delivery) style for developing products and services, (whether startups or large established organisation), everyone today has to thrive by innovating and adapting to the latest trends in technology. They have to keep themselves ahead in the race to delight customers. Full stack developers are key players in experimenting and delivering value consistently using varied tools and technologies throughout the stack.
In this session I'll be share my journey of how I became a full-stack developer. Hopefully this will help others understand how they can target and plan to gradually become a full stack developer in their respective teams.
Also I'll highlight the following topics:
- What is the importance of a full stack dev?
- What tools/resources/languages in my experience work best for full stack developers?
- Downsides of being a full stack developer!
Outline/Structure of the Experience Report
- Factors that pushed me to embrace the full-stack developer mindset (5 mins)
- Quick intro to the concept of full-stack developers and expectations from them (5 mins)
- How I began my journey (tools, resources, people, etc.) (5 mins)
- Challenges faced along the way and how I resolved them (10 mins)
- Benefits & Downsides of being a full stack dev (10 mins)
- Based on my experience, recommendations on how to plan becoming a full stack dev (5 mins)
- Q & A (5 mins)
- Insight into Full stack dev culture/mindset
- Role of full stack dev in your team's success
- Planning your full-stack dev journey
- Things to watch out for when embracing the full-stack dev culture
Founders, Engineers, Managers and People planning to start their Entrepreneurial Journey
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Naresh Jain - Dark Side of Collaboration
On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.
It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.
In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.
Naresh Jain - MVP Design Hacks
A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:
- are we solving the right problem?
- if yes, how do we pitch the idea to the target customer to generate a favourable action?
During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.
Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.
To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.
However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.
Naresh Jain - The Decline and Fall of Agile - Antifragile Mindset to Rescue
What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty and simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.
Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.
In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.
Naresh Jain - Test Driving a React.js UI Component with Jasmine
Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) & Behaviour Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work. While TDD has seen a great adoption on server side, developers still find it hard to apply TDD for developing UI components.
In this hands-on, live coding demo, Naresh will build a web commenting and discussion feature (like Disqus) in React.js, 100% test driven. He will also demonstrate how TDD will help us drive an object-functional design to strike a pragmatic balance between the Object-Oriented and Functional Programming paradigms.
Pavel Dabrytski - Agile Economics: Contracts, Budgets, CapitalizationPavel DabrytskiAgile CoachThink Agile
schedule 3 years agoSold Out!
How much does one story point cost? Is Sprint 0 an expense or an asset? Can you run Scrum with a fixed-cost contract? Agile challenges the existing approach to financial aspects of running projects: i.e. budgeting, forecasting, financial planning and vendor contracts.
Applying new financial models becomes increasingly important for larger organisations adopting Agile. While they are going through an Agile transformation, they also need to maintain transparent financial governance and reporting. Shareholders would not be too excited about messy Annual Financial Statements.
Join me if you would like to know more about Agile Economics. No financial degree is required and all the content explained in plain English with plenty of pictures!
Ellen Grove - Everything Is Better When We Stick Together: Building Team Working AgreementsEllen GroveAgile Coach and TrainerAgile Partnership
schedule 3 years agoSold Out!
Whether a team is brand-new or seasoned veterans at working together, explicitly defining and/or refining a team working agreement will help the team to align on how they will work together effectively to meet their common goal. In this fast-paced hands-on session, participants will go through the process of building a team working agreement using LEGO Serious Play (LSP).
Creating a team working agreement helps team members set the stage for effective communication and high performance by making assumptions about ‘what really matters to us’ and ‘how we will work together?’ explicit and negotiable. Great working agreements address some difficult topics - what values do we share? how do we want to deal with conflict when it comes up? how will we handle problems within the team? - which are often challenging to discuss openly and honestly, especially when a team is first assembled.
This session will show you how to use LEGO Serious Play to encourage a frank and fearless discussion in order to kickstart these discussions so that a team can quickly create a powerful set of simple guiding principles for working together. Participants will learn about the importance of team working agreements in creating team cohesion and common understanding of shared values and operational guidelines, and experience hands-on how to use the LEGO Serious Play cycle of build-share-reflect to have a participatory discussion to identify shared values, explore reactions to conflict, and build a set of simple guiding principles.