Jekyll2022-11-11T22:48:16+00:00https://rufusraghunath.com/feed.xmlRufus RaghunathEngineer. Multiplier. Purveyor of armchair philosophy.Farewell, AngularJS: A study in UI legacy migrations2021-05-12T00:00:00+00:002021-05-12T00:00:00+00:00https://rufusraghunath.com/2021/05/12/farewell-angularjs<h1 id="farewell-angularjs-a-study-in-ui-legacy-migrations">Farewell, AngularJS: A study in UI legacy migrations</h1>
<p>The term “legacy migration” typically carries connotations with more server-side and infrastructure concerns, such as breaking up a monolithic application into microservices, or moving from on-prem hosting to the cloud. It’s not always well-understood that modernizing legacy user interface applications (UIs) can be just as important.</p>
<p>When discussing legacy UI migration with our clients, we often hear questions such as, “Will we have to migrate this UI again any time soon? Is it really worth doing if we’re just going to end up changing it again?” Technical directors and architects are usually (and understandably) concerned about the fast-paced JavaScript ecosystem, which is critical to modern UI development.</p>
<p>We believe that this is the wrong way of thinking about the issue. While the JavaScript ecosystem has currently stabilized around a handful of best-in-class frameworks, we should always expect disruption in the space where technology meets its users. User interfaces are always at the cutting edge of technical progress, and users’ expectations are always increasing.</p>
<p>Therefore, there is a tremendous potential payoff for organizations that get good at supporting constant change in their UIs. The principles of evolutionary architecture can be applied to UI development to great advantage — for example, certain architectural patterns, like micro frontends, can be used to ease the process of migrating while keeping your core business functionality protected.</p>
<p>To understand what this looks like in practice, let’s examine the case of AngularJS, the frontend technology that we have most frequently helped clients migrate away from in recent years. We’ll reflect on our long experience of migrating legacy UIs more generally, while using AngularJS as a specific example to guide our thinking. Whether you are currently on AngularJS or another UI framework, you’ll come away from this article a little more prepared to modernize your UI.</p>
<p><em>Read the full article on <a href="https://www.thoughtworks.com/insights/articles/farewell-angularjs">ThoughtWorks Insights</a>.</em></p>Farewell, AngularJS: A study in UI legacy migrationsBe an AIDER: Five steps for new Tech Leads to structure their people leadership2021-05-10T00:00:00+00:002021-05-10T00:00:00+00:00https://rufusraghunath.com/2021/05/10/be-an-aider<h1 id="be-an-aider-five-steps-for-new-tech-leads-to-structure-their-people-leadership">Be an AIDER: Five steps for new Tech Leads to structure their people leadership</h1>
<iframe src="https://www.youtube.com/embed/3tig5EMQcdU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p><br /></p>
<h2 id="abstract">ABSTRACT</h2>
<p>Many new tech leads struggle with people leadership. It can be confusing to go from individual contributor to enabler of teams and people. Many existing learning resources rely heavily on qualitative reports and general advice, which can be difficult to parse and apply for those only just taking their first steps in the tech lead role. In this talk, we’ll demystify this aspect of being a tech lead and take a gardener’s perspective on growing our teams. Using the easy-to-follow AIDER framework, we’ll identify five clear steps any beginning tech lead can take to nourish individuals and cultivate great teams.</p>Be an AIDER: Five steps for new Tech Leads to structure their people leadershipIntroducing Kelda.js: A threadpool for the browser, built on top of Web Workers2020-12-18T00:00:00+00:002020-12-18T00:00:00+00:00https://rufusraghunath.com/2020/12/18/introducing-keldajs<h1 id="introducing-keldajs-a-threadpool-for-the-browser-built-on-top-of-web-workers">Introducing Kelda.js: A threadpool for the browser, built on top of Web Workers</h1>
<iframe src="https://www.youtube.com/embed/IMo0K22IRAo" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p><br /></p>
<h2 id="abstract">ABSTRACT</h2>
<p>The browser is the most resource-constrained environment we are likely to write code for. In this talk, Rufus will present his new open-source library, Kelda.js, which allows you to comfortably do threading in the browser without messing around with Web Workers yourself. We’ll talk about the challenges of building on top of the Web Worker API and dive into the tradeoffs Kelda makes to deliver something usable. We’ll also take a detailed look at several alternative patterns for optimizing JavaScript performance in the browser runtime, such as virtualised scrolling, to help you identify a good usecase. You almost certainly don’t need a browser thread pool - but if you do, there’s Kelda!</p>Introducing Kelda.js: A threadpool for the browser, built on top of Web WorkersEvolutionary UI: Change as a first-class citizen in the modern frontend world2019-12-13T00:00:00+00:002019-12-13T00:00:00+00:00https://rufusraghunath.com/2019/12/13/evolutionary-ui<h1 id="evolutionary-ui-change-as-a-first-class-citizen-in-the-modern-frontend-world">Evolutionary UI: Change as a first-class citizen in the modern frontend world</h1>
<iframe src="https://www.youtube.com/embed/QNRv-KyhVK0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p><br /></p>
<p>This year, I was fortunate enough to speak at the <a href="https://conferences.oreilly.com/software-architecture">O’Reilly Software Architecture Conference</a> in Berlin. Together with <a href="https://giamir.com">Giamir Buoncristiani</a>, I showed how the principles of <a href="https://evolutionaryarchitecture.com/">Evolutionary Architecture</a> can be applied to UI development to create what we call <em>Evolutionary UI</em>. We relied heavily on our experience leading the ThoughtWorks Frontend Community in preparing this material, which allowed us to incorporate not only our own observations, but the learnigs of hundreds of our colleagues worldwide. We presented a significantly reworked and improved version of this talk, which we previously gave at JSDay.</p>
<p>Thanks to <a href="http://nealford.com">Neal Ford</a> and the ThoughtWorks Frontend Community for their kind feedback on our work.<br /><br /></p>
<h2 id="abstract">ABSTRACT</h2>
<p>Allowing for change is especially important when designing your frontend applications, where ever higher user expectations meet the fast-paced JavaScript ecosystem.</p>
<p>In this talk, we will show how the principles of evolutionary architecture can be applied to UI to prioritize changeability. We’ll consider several approaches to making a modern UI application more evolvable, such as the controversial microfrontends pattern, and examine specific “fitness functions” that will keep you and your team honest to your requirements without sacrificing evolvability. We’ll also discuss the tradeoffs you make when you choose a more evolutionary frontend architecture, and provide a framework for thinking about how much future change you’ll need to account for.</p>Evolutionary UI: Change as a first-class citizen in the modern frontend worldDeveloping and testing WebSocket-based applications using React and STOMP2019-10-27T00:00:00+00:002019-10-27T00:00:00+00:00https://rufusraghunath.com/2019/10/27/react-and-stomp<h1 id="developing-and-testing-websocket-based-applications-using-react-and-stomp">Developing and testing WebSocket-based applications using React and STOMP</h1>
<p>We recently added a real-time component to a complex application my team is working on. We have a React frontend and a Java SpringBoot backend, so naturally we looked for existing ways to seamlessly integrate <a href="https://en.wikipedia.org/wiki/WebSocket#:~:text=WebSocket%20is%20a%20computer%20communications,WebSocket%20is%20distinct%20from%20HTTP.">WebSocket</a> into this tech stack. One developer-friendly way to do this is to leverage <a href="https://stomp.github.io/">STOMP</a>, a nice abstraction on top of WebSocket that handles a lot of vexing, message-related problems for you out of the box.</p>
<p>While there was good support for STOMP in the Java world, I was surprised to find very little for React, in particular for testing. I ended up hand-rolling a React STOMP client, as well as a mock STOMP broker for exercising said client in our automated tests.</p>
<p>Since I went to all this trouble, I thought I might as well extract the functionality into two libraries and open-source it. You can install <a href="https://www.npmjs.com/package/react-stomp-client">react-stomp-client</a> and <a href="https://www.npmjs.com/package/mock-stomp-broker">mock-stomp-broker</a> from npm, and find the source code on <a href="https://github.com/rufusraghunath/js-stomp-utils">GitHub</a>.</p>Developing and testing WebSocket-based applications using React and STOMPOn Asynchronicity: Heraclitus slays Zalgo2018-12-25T00:00:00+00:002018-12-25T00:00:00+00:00https://rufusraghunath.com/2018/12/25/heraclitus-slays-zalgo<h1 id="on-asynchronicity-heraclitus-slays-zalgo">On Asynchronicity: Heraclitus slays Zalgo</h1>
<iframe src="https://www.youtube.com/embed/C3GvXp4Detk?start=1572" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
<p><br /></p>
<p>This is a 5-minute lightning talk I gave at <a href="https://www.youtube.com/playlist?list=PLe9psSNJBf75O6abYvvjxhm36_QU9H-f2">Fullstack Fest 2018</a>, which combines my trademark uneducated armchair philosphy with some JS jargon.</p>
<p>The Greek philosopher Heraclitus once said:</p>
<blockquote>
<p>Upon those that step into the same river, different and again different waters flow.</p>
</blockquote>
<p>I take this to mean that there is no such thing as true identity. There is no river, because what we perceive as the river is in fact always changing. This statement inspired me to look at the different ways we have handled asynchronicity in the JavaScript ecosystem*, because I believe that letting go of identity has allowed us to remove a whole class of bugs that occur when we model reality in a way that presupposes that there exist mutable entities that remain “the same” even as their observable values change.</p>
<p>In this talk, I discuss how the problem of <a href="http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony">“releasing Zalgo”</a> (h͢e̴ ̵wh͝o ẁa̧i̛t̕s͟ ̵b͠ȩhi̷n̡d t͡h̵e͡ ͡wall) when working with APIs that are <em>unpredicably</em> asynchronous no longer applies when using Promises. Since correct use of a <code class="language-plaintext highlighter-rouge">Promise</code> involves lifting all operations that depend on the resolved value into the context of the value (using <code class="language-plaintext highlighter-rouge">.then()</code>), your program cannot end up in an inconsistent state. This is in contrast to earlier approaches, such as using callbacks, that would have involved modifying outside state (a mutable identity) that is referred to by other parts of the program, thus creating the potential for a race condition.</p>
<p>Apologies up-front that I’m not particularly polished or easy to follow here. I decided to do this talk on a whim, and it essentially became a brain-dump of things I had been thinking about recently ¯\<em>(ツ)</em>/¯</p>
<p>Here are the articles and talks I refer to:</p>
<ul>
<li><a href="https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey"><em>Are We There Yet?</em></a>, by Rich Hickey</li>
<li><a href="http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony"><em>Designing APIs for Asynchrony</em></a>, by Isaac Schlueter</li>
<li><a href="https://medium.com/@bluepnume/intentionally-unleashing-zalgo-with-promises-ab3f63ead2fd"><em>Intentionally unleashing Zalgo with synchronous promises</em></a>, by Daniel Brain</li>
</ul>
<p>* In this example I’m talking about callbacks and Promises, but the same principle applies outside the JavaScript ecosystem.</p>On Asynchronicity: Heraclitus slays ZalgoDividing Frontend from Backend is an Antipattern2018-03-29T00:00:00+00:002018-03-29T00:00:00+00:00https://rufusraghunath.com/2018/03/29/dividing-frontend-from-backend-is-an-antipattern<h1 id="dividing-frontend-from-backend-is-an-antipattern">Dividing Frontend from Backend is an Antipattern</h1>
<p><em>This article was <a href="https://www.thoughtworks.com/insights/blog/dividing-frontend-backend-antipattern">originally published</a> on <a href="https://www.thoughtworks.com/insights">ThoughtWorks Insights</a>.</em></p>
<p>We software developers have historically used the terms “frontend” and “backend” to describe work on client-side (e.g., browser) and server-side applications, respectively. This conceptual split has evolved into the creation of specialized developer roles for each, which is still the norm throughout the industry. In practice, this is an arbitrary split that is too often used to avoid work we don’t want to do. It creates team dynamics that make it unnecessarily difficult to integrate client and server-side functionality and deliver quality software. This is particularly harmful in modern teams, which face increasingly complex client-side work.</p>
<p>And yet, I come across the frontend/backend mindset regularly, even at the most technologically progressive companies. After spending a year introducing modern JavaScript on my <a href="https://www.thoughtworks.com/insights/blog/advocating-software-quality-metro">previous project</a>, I was told to stop focusing on frontend because “we’re application developers”. Every developer I’ve ever met who has exceptional ability in client-side work has similar stories to tell. This dismissive attitude speaks both of a failure to understand how much JavaScript and the whole frontend ecosystem <a href="https://stateofjs.com/2017/introduction/">have evolved</a> in recent years, and of a close-mindedness that makes it hard for our teams to adapt and deliver software to the expectations of the modern market.</p>
<p>Dividing frontend from backend is an antipattern. If you are someone who still feels that there is merit to a hard distinction between these roles, this article is for you.</p>
<h2 id="we-already-do-the-same-work-in-the-frontend-and-the-backend">We already do the same work in the frontend and the backend</h2>
<p>What does a frontend dev actually do that’s so different from a backender? The feeling seems to be that backend devs have historically done the more ‘serious’ programming, thinking about meaningful issues such as testability, maintainability, persistence, asynchronicity, state management, and API design, while their frontend colleagues flitted about making things look pretty. If frontend devs did any serious coding at all, it was probably some hacky, half-understood jQuery, cobbled together from various Stack Overflow posts. Many folks still think along these lines.</p>
<p>Here’s the reality: JavaScript has absolutely exploded in the past few years. Nowadays, with the advent of ever more complex client-side applications (think responsive, immersive, offline-enabled experiences), significant chunks of functionality are moving from the backend to the frontend. We now think about the same problems in the front as in the back. The issues I listed earlier (testability, maintainability, persistence, asynchronicity, state, API design) are now the daily bread of client-side developers.</p>
<p>But we don’t just share the same problems — we also solve them in a similar way. Functional abstractions are emerging as universally useful, such that we can often use the same concepts and syntax in the client and the server. Just look at <a href="http://reactivex.io/">ReactiveX</a>, now implemented in so many languages that you could easily build a project on the same reactive abstractions in the front and the back. Then there’s the revolution of <a href="https://reactjs.org/blog/2013/06/05/why-react.html#reactive-updates-are-dead-simple">declarative rendering</a>, which has made the view layer far more testable and stable. On the architecture side, microfrontends have become so popular that we’ve <a href="https://www.thoughtworks.com/radar/techniques/micro-frontends">added them</a> to the ThoughtWorks <a href="https://www.thoughtworks.com/radar">Technology Radar</a> alongside their backend equivalent, microservices. It doesn’t make sense to keep the distinction between frontend and backend development when we’re all doing such similar work.</p>
<h2 id="we-need-to-build-broad-frontend-capability-to-future-proof-our-companies">We need to build broad frontend capability to future-proof our companies</h2>
<p>Client-side engineering is a serious business need. JavaScript is taking over the world, and we can’t afford excellent and experienced devs thinking of User Interface (UI) and User Experience (UX) work as outside of their area of concern. At ThoughtWorks, we are seeing more and more engagements that involve a revamp or total rewrite of our client’s browser and mobile applications to align with the needs of modern consumers. In other words, actively building and maintaining client-side capability is critical to surviving in today’s market — not to mention tomorrow’s.</p>
<p>You might think that the correct solution here is to simply hire more engineers into traditional ‘UI Developer’ roles. But it’s not, for two reasons. Firstly, recruiting and retaining experts is <a href="https://medium.com/javascript-scene/why-hiring-is-so-hard-in-tech-c462c3230017">famously challenging</a> in the tech industry. Thus, our focus should instead be on enabling our existing workforces in frontend development — particularly given the similarity of modern frontend and backend work. Secondly, having dedicated UI Developers promotes problematic team dynamics. How many of us have been on teams where all or most frontend architecture and development was relegated to “that JavaScript person”? This can lead to information silos, less solid testing, and an overall reduction in code quality, which in turn poses a serious business risk.</p>
<p>At the end of the day, a lot of us simply dislike styling and other areas of frontend that come uncomfortably close to design. Last year I heard a conference speaker quip that she shouldn’t have to care about something as unimportant as ‘presentation logic’. We have evolved a culture of disdain for frontend which protects us from having to learn since it’s not ‘real coding’ anyway. It’s an attitude that makes it hard to keep up with the market and continue to create meaningful products for humans.</p>
<h2 id="we-should-care-about-how-our-programs-consumed">We should care about how our programs consumed</h2>
<p>Ironically, the crown jewel of backend quality is and always has been user interface design. Every design pattern ever invented, every book on architecture ever written, every DRY refactoring ever performed: all tools to help the authors of code enhance the productivity and happiness of the readers of code. Whether you’re creating an inheritance hierarchy, an API, or an ecosystem of microservices, you’re creating it for someone. If you’d be embarrassed to release an un-RESTful API or a class with leaky abstractions, then you care about user interfaces. So we already think of software quality in terms of user experience — it’s just that the users happen to be other developers.</p>
<p>As proud craftspeople, we should care about how our programs are consumed, whether through an API or a UI. At ThoughtWorks, we think of our roles as fluid and non-exclusive areas of championship. For example, while we usually have dedicated QAs on our teams, we consider quality to be everyone’s responsibility. In the same way, we should take collective responsibility for the full stack of technologies we use, and thus ultimately for the quality of the product we produce. Successful engineering organizations understand this. Tech legend Kent Beck, the inventor of <a href="https://en.wikipedia.org/wiki/Extreme_programming">Extreme Programming</a> and signatory to the original <a href="http://agilemanifesto.org/">Agile Manifesto</a>, has <a href="https://soundcloud.com/thoughtworks/is-tdd-dead-episode-3-feedback?in=thoughtworks/sets/is-tdd-dead#t=17:28">said</a> that hanging on his office wall is a poster bearing the following sacred mantra: “Nothing at Facebook is somebody else’s problem”.</p>
<h2 id="stay-open-minded">Stay open-minded</h2>
<p>Contemporary frontend work has evolved in complexity to the extent that we should no longer separate frontend from backend roles. Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.</p>
<p>To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is. While it is perfectly valid to dislike a particular technology, such as CSS, the industry’s culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.</p>
<p>Think of yourself as a developer first. <a href="https://frontendmasters.com/books/front-end-handbook/2017/">Investigate frontend technologies</a>, pair with UI specialists, evangelize your colleagues. Your team, your company, and your users will thank you.</p>
<p><em>Thanks to Nathan Zeplowitz, Luke Belliveau, and Robin Weston for their excellent constructive feedback.</em></p>Dividing Frontend from Backend is an AntipatternHow to Be a Junior Software Developer2017-09-20T00:00:00+00:002017-09-20T00:00:00+00:00https://rufusraghunath.com/2017/09/20/how-to-be-a-junior-software-developer<h1 id="how-to-be-a-junior-software-developer">How to Be a Junior Software Developer</h1>
<p><em>This article was <a href="https://www.thoughtworks.com/insights/blog/how-be-junior-software-developer">originally published</a> on <a href="https://www.thoughtworks.com/insights">ThoughtWorks Insights</a>.</em></p>
<h2 id="introduction">Introduction</h2>
<p>In my time as a junior at ThoughtWorks, I was blessed to have opportunities to grow and develop my skills on several interesting projects, with the help of some amazing people. In this article, I want to share the strategy I used to maximize my professional development. If you’re in a similar position, I hope this will help you make your first steps into tech successful. If you’re a senior or team lead, I hope that this will help you to support juniors in growing and becoming productive. If you’re a company, I hope that this will provide some context for how to hire and staff junior developers.</p>
<h2 id="learning-to-learn">Learning to learn</h2>
<p>I think it’s important to realize that, as a junior, your main value to an employer is most likely your potential, not your current ability. ThoughtWorks certainly didn’t hire me because they thought my technical interview solution should be pushed to production anywhere. So rather than focusing on delivering software 100% of the time, focus on up-skilling. Practice self-reflection and seek feedback to identify your weaknesses. Use whatever resources are available to you to improve your knowledge and skill set. Ask for help from seniors, ask for code reviews, pair program. Understand the context in which you are working - talk to business analysts, QAs, stakeholders, ask questions. Don’t stop moving, cultivate a humble ‘always learning’ attitude. Gain perspective on alternative ways to do things.</p>
<p>Learning itself is a skill that can be developed. I did not join ThoughtWorks with a particularly broad range of technical skills, and so, every project I joined brought a panic-inducing flood of new programming languages, new tools, new frameworks, and new concepts crashing down on me (and that’s not even mentioning business-related skills). These are the moments when <a href="https://en.wikipedia.org/wiki/Impostor_syndrome">impostor syndrome</a> is at its strongest and undermines your self-belief the most. After a while, though, you begin to spot the pattern. It goes something like this:</p>
<ol>
<li>Enthusiasm</li>
<li>Bafflement</li>
<li>Superficial comprehension</li>
<li>Frustration, having your expectations violated</li>
<li>Working knowledge, productivity</li>
<li>Rinse and repeat</li>
</ol>
<p>Stage 3 is the most dangerous since in it you’re unaware of your own failure to understand what you’re doing. Better to be frustrated and proactive in seeking help than to cheerfully cook up vats of spaghetti code without knowing any better. Ironically, one can be quite ‘productive’ in stage 3. Get out of stage 3 by seeking feedback on your work and developing a relationship with your ignorance. Embrace it as a temporary given.</p>
<p>Once you’ve gone through this cycle a few times and ended up able to ship respectable production code in a new technology, you develop a ‘can do’ attitude towards learning. You become confident in your ability to pick up new things quickly and start to enjoy it. And, more importantly, you can make a plausible, evidence-based case for this to business stakeholders when needed. I have found that even senior developers sometimes end up lacking this panache because their roles have been too one-sided and have not required them to stretch. So, continuously extract yourself from your comfort zone and put yourself in the situation of having to learn new things - this experience will become your primary advantage as a junior developer, particularly if you work as a consultant. Set the tone for the rest of your career.</p>
<h2 id="adding-value-as-a-junior">Adding value as a junior</h2>
<p>Learning is all very well, but at some point, you need to get into the grind and rhythm of delivering software. Apart from your daily work, which will probably involve small and de-risked chunks of responsibility, I strongly recommend that you seek out independent areas in which you can add value to your team and turn them into pet projects.</p>
<p>For example, on my first project, we used C# in the back and React + Redux in the front. Since I hadn’t used any of these before, the barrier to entry to productivity was fairly high. I was lucky to have a tech lead who understood the importance of delegating other useful tasks to me, to keep me confident and productive while learning to use our core delivery stack. In this case, we were using an incomplete <a href="https://github.com/elrob/build-mon">open-source build monitor tool for Visual Studio Online</a>, so it became my task to finish implementing it.
For context, I had no idea how build pipelines worked, and as it turned out, the monitor was written in Clojure, which has a paradigm that is hilariously different to the object-orientation I was used to. So for a month, I spent my nights producing horribly imperative Clojure code and watching talks by Rich Hickey. By the end, our team had a working build monitor and I had discovered my love of functional programming.</p>
<p>My next project was working on a Java microservices platform using Docker, Kubernetes, and Cassandra. Once again, a new tech stack. This time, I bridged the time needed to get ramped up on the new tools and concepts by making myself useful in the UI. I used my previous experience to help advocate for and execute a <a href="https://www.thoughtworks.com/insights/blog/advocating-software-quality-metro">migration of critical business flows from Reflux to Redux</a>. This increased the testability of our JavaScript and reduced the complexity of our inherited codebase, which in turn resulted in improved velocity and stability.</p>
<p>In both cases, I needed time to learn and become productive. By identifying things I could do, I was nevertheless able to start delivering genuine value to my teams quickly. These pet projects helped me build credibility and trust with my team and stakeholders, improved my confidence and reduced impostor syndrome, and allowed me to experiment with taking the lead on something (which is a whole world of learning unto itself).</p>
<p>There is always some extra utility to produce or something to refactor. While pursuing pet projects is particularly helpful for your development and team relationships as a junior, it’s a habit that I’ll continue to cultivate. It’s just so fun!</p>
<h2 id="choosing-pet-projects">Choosing pet projects</h2>
<p>Sadly, there’s no such thing as a free lunch. Like everything, the utility of pet projects comes at a cost. You may be uncertain or confused about where to start. You may not feel supported, or you may feel pressured to deliver functionality. You might be worried about the extra time, work, and effort required.</p>
<p>From experience, I can confirm that those are all real and valid challenges. In addition, expect to be continually frustrated and have your expectations of how things are supposed to work continually violated. To ameliorate these issues, I suggest that you pick projects that:</p>
<ul>
<li>Are small</li>
<li>Have clear goals (definitions of ‘done’)</li>
<li>Add value/will be appreciated</li>
<li>Are likely to be supported once you advertise them (e.g. by team, company, community)</li>
<li>Are fun/rewarding in their own right</li>
</ul>
<p>Moreover, embrace both failure and ignorance. Suspend your disbelief that it will work tomorrow. Suspend your disbelief that you will understand it tomorrow.</p>
<p>And, of course, give yourself time off as well. Taking on pet projects is helpful and fun, but the expectation certainly shouldn’t be that you have to put in extra work beyond what you’re paid to do. Choose to do so when it makes sense for you, and when you have the space for it in your life. You can also speak to your team to see if they’ll allow you time to work on pet projects within work hours, which is definitely possible if there’s a clear value-add.</p>
<h2 id="conclusion">Conclusion</h2>
<p>One of the key tenets of the <a href="http://agilemanifesto.org/">Agile Manifesto</a> is to prefer ‘responding to change over following a plan’. Continuous Improvement, Continuous Delivery. Produce a version of the product, observe its shortcomings, collect feedback, reassess requirements, produce the next version. Iterate in small chunks, never impose a grand vision based on outdated information. As a junior developer, it’s useful to think of yourself in the same way.</p>
<p>Keep learning.<br />
#juniordevforlife</p>How to Be a Junior Software DeveloperMigrating from Reflux to Redux2017-05-05T00:00:00+00:002017-05-05T00:00:00+00:00https://rufusraghunath.com/2017/05/05/migrating-from-reflux-to-redux<h1 id="migrating-from-reflux-to-redux">Migrating from Reflux to Redux</h1>
<p>I recently helped my team move a large codebase from <a href="https://github.com/reflux/refluxjs">Reflux</a> to <a href="http://redux.js.org/">Redux</a> (I have written exensively about my experience on <a href="https://www.thoughtworks.com/insights/blog/advocating-software-quality-metro">ThoughtWorks’ <i>Insights</i> blog</a>). Both are JavaScript-based state-management tools. This was an interesting technical challenge, and a fun one.</p>
<p>Because Reflux and Redux both follow the basic <a href="https://github.com/facebook/flux">Flux</a> architecture pattern of unidirectional data flow, we can incrementally take over the Reflux state cycle with Redux:</p>
<ol>
<li>Complete Reflux cycle</li>
<li>Action handling (e.g. async) in Reflux, but keep all state in Redux. Reflux store action listeners dispatch Redux actions with the results of remote API calls and no longer call <code class="language-plaintext highlighter-rouge">this.trigger</code>. React components receive props mapped to Redux state and no longer listen to Reflux stores. At this point, Reflux essentially acts as async middleware for Redux.</li>
<li>Action handling (e.g. async) in Redux, with appropriate middleware. Reflux store action listeners now do nothing but straight away dispatch corresponding Redux actions.</li>
<li>Complete Redux cycle – stop dispatching Reflux actions from React components and start directly dispatching Redux actions.</li>
</ol>
<p><img src="/assets/redux-migration.png" alt="Redux Migration - Technical Diagram" /></p>
<p>Thus, you can break the refactor up into bite-sized chunks and spread it out over time if required (e.g. due to other high-priority work/new scope coming in), keeping your app fully functional at every stage.</p>Migrating from Reflux to Redux