Three weeks ago I began learning the JavaScript React framework.
I had a fair amount of knowledge about basic coding principles (functions, objects, looping, etc.) before beginning the Flatiron coding bootcamp. I had taken a C++ programming class in engineering school, had used code to manipulate data for several engineering courses, and had had several internships/undergraduate research projects which were heavily focused on developing code for sensors for environmental monitoring. However, in each of these applications of my coding knowledge, the work was single-track; I was either provided access to an existing library of code to make surgical modifications to it, or was given an assignment of relatively limited scope such as solving an algorithmic problem on a school project. In both cases, I coded independently and without much need to concern myself with the larger context into which my work would fit. The well-bounded scope of these tasks kept things simple for me.
I coded independently and without much need to concern myself with the larger context into which my work would fit...this is not what coding in the real world is like
This is not what coding in the real world is like. Everything I've learned about real-world programming - from instructors, software engineer friends, and personal research - has consistently indicated that it is a far more complex, context-specific, and team-oriented task than my academic pursuits would indicate. The algorithmic problem solving skills that I developed, while important for demonstrating aptitude, are not the be-all-end-all measure of a programmer's ability. Much more important is the programmer's skill in leaving a clear and logical breadcrumb trail through all of their work so that it can be understood as it is revisited over the following years and potentially even decades.
While software engineers can and certainly should develop skills at writing logical, clear, and well-documented code independently from scratch, with the complexity of modern software even the most communicative and well-intentioned programmers may find themselves struggling to synchronize their work with that of their team. The beauty of software - its incredible flexibility - makes it the most significant technology of our era while simultaneously making it a many-headed hydra that, if not kept in check under strict organizational principles, can get out of control of even the most capable teams. Ten Javascript engineers, each left to write a moderately complex program from scratch, will come up with ten very unique codebases. Over time software engineers have built tools, techniques, and principles such as Single Responsibility and Separation of Concerns for ensuring comprehension and interoperability regardless of the original author. However, at a certain point, the flexibility inherent to any programming language becomes its Achilles' heel.
At a certain point, the flexibility inherent to any programming language becomes its Achilles' heel
This is where frameworks, such as React.js, become relevant. While many companies building their codebases with vanilla JavaScript have undoubtedly created their own design and organization paradigms to structure their teams' approach to software development, React takes this a step further: it bakes its design paradigm into the very structure of its code by using JSX to render Components. While a stubborn and uninformed engineer could still manage to create an entire web app in one component, the structure of React lends itself to the reduction of a webpage's elements into a collection of simpler components which adhere to Single Responsibility/Separation of Concerns in their own unique way. Thus, React deftly sidesteps the single greatest issue with building scalable code, by providing a framework that at every step gently nudges programmers towards a set of standard procedures, all while maintaining the flexibility that makes software engineering such a uniquely powerful technology.
Although I did not immediately see the usefulness of React when I started learning the syntax three weeks ago, I've since come to understand why it has become the most popular javascript framework to date. This was cemented during the Phase 2 project, in which our group was able to follow the principles of Thinking in React by sketching out a component hierarchy, dividing up the components, and assigning each person to develop a different component. Even with relatively little experience in software architecture and programming workflows we were able to work in parallel on a somewhat complex assignment, each completing a functional piece of the website with minimal discussion of our organizational strategy or principles of design. We operated as a team based on design principles that, if we're being honest, we likely aren't even fully aware of, because these principles are inherent to the way that React functions. And that's pretty remarkable, if you ask me!
Cover image sourced from Tech Diagonal
Top comments (0)