The secret ingredients to being a full stack developer
Take about 500ml of AngularJS, throw in 100g of NodeJS, leave to settle for 5 minutes and add a sprinkling of Neo4j. Add this mix to the oven at 220C for 25 minutes. When the 25 minutes have elapsed, remove from the oven and season with some Continuous Delivery and voila! OK I’ll admit; this is not going to be a post that will detail the secret ingredients to finding or being this kind of developer.
So the real goal of this article is to try and ascertain what we really mean by being or looking for a full stack developer. But more so, to put it to you, the community of what you think we need to be considering if we are to truly feel that we can confidently cover all aspects of the requirements of being a full stack developer. I’m going to try and break the areas down into layers of considerations based on my knowledge of the things we need to be taking into account when not only creating applications, but also where they live, what they do and how they affect us, our clients and our users. I’m only going to be scratching the surface on all the consideration aspects. I’m sure there are many more, and I could possibly write an entry to the blog for each layer in the stack of being a full stack developer.
Being a full stack is something I strive to be, but it’s hard. The landscape is continuously evolving and it’s the trying to keep up with the leading ways of working with the various areas of application development is when it becomes tricky. Are we front-end, back-end and database experts? Or are we front-end, back-end and database generalists with focus on one of the layers as a specialist? With a move towards the Sword Shaped Developer (more on this later in the post). Let’s try and break this down.
Say you are a developer who tries to be full stack and you have been tasked with building a funky new CMS for your company, client or yourself. When thinking about all the layers involved in the stack, let’s say you start with devising how the front-end will work, but what do you do, what do you use?
I’m going to cover the following development considerations:
- The Front-end Developer
- The Back-end Developer
- The Database Developer
- The Architect Developer
- The Ops Developer
- The InfoSec Developer
- The Agile Developer
- The T-Shaped Developer
Today there are many ways to build out a front-end, whether you use a JavaScript Framework or a server side framework that does all the rendering on the server and displays to the client like ASP.NET MVC orWebForms. But, today there are many ways to skin a cat in regards front-end, there are JavaScript frameworks coming out nearly every second! If you check under the carpet there is likely to be one there that someone forgot about.
It’s becoming very difficult to keep up with what are the leading frameworks to use. But, not only is knowing what front-end framework to apply becoming more and more difficult, but also front-end devs need to know how to test, do you use Jasmine or qUnit integrated with task automation runners like Grunt or Gulp. Use of CSS frameworks like Bootstrap or floatz for building responsive applications. Use of CSS pre-processors like Less or Sass. Knowledge of HTML, with the advancement of HTML5 and building for backward compatibility in browsers and mobile devices. Backward compatibility is yet another topic, but JavaScript 6 will be upon us soon, and with that, not all browsers will support some of its features. Use of transpilation tools like Traceur and Babel will become key here and is something that needs to be factored into this area of development. But we also need to consider application page performance and web accessibility standards. Another area of consideration may be SEO and how the application will perform with rankings based on how the content is displayed. A final area that may need to be taken into account is the design with the use of tools such as Illustrator, Photoshop and Balsamiq as a requirement.
Once you’ve decided on how you will build your front-end, how is it going to communicate with your data layer. What do you need to consider when building your middle-tier?
Today, there is much more of a focus on scalability of applications which is something that needs to be considered from the off. And, in doing so, we try to build cloud optimised applications that can adjust to auto-scale when required. Whether we’re using RackSpace, Azure, and/or AWS etc. Frameworks are becoming more modular as we start to use only what is required for our application to run. You can see this with the latest addition to the .NET family with ASP.NET 5. This is allowing us to build potentially sacrificial architectures with some focus on micro-services.
There are a variety of server side options these days to help achieve the middle tier, but knowing which the best option is again, is sometimes the hard part. For example, you can run JavaScript as a server side component with NodeJS, you could use MVC, Web API, Web Forms, WCF, SignalR etc. Like the front-end, knowing how to test and what to use is an essential part, using TDD or BDD with NUnit, MSTest, MOQ, SpecFlow, Selenium etc.
We need to consider the use of design patterns and principles, such as dependency injection or one of my favourite design patterns, the strategy pattern (there are many and will continue to be many more). Of course, stepping back to the front-end development, design patterns and principles like the dependency inversion principle will still apply to how you build out your front-end too. You may need to consider how you will achieve dependency injection, whether to use Unity, Castle Windsor or Ninject on the back-end or using AngularJS’s built in feature for this. There should be a conscious effort on how you present your written code. Keeping in mind you are writing software that may be read by fellow devs with using strategies like following Kent Becks simple design rules or use of StyleCop and FXCop.
Considerations need to be made on how your application works in the environment it lives on. For example, if it’s a web app, can it be self-hosted or run on IIS, and if so, what considerations you may need to make when working against IIS and the it’s particular version. Are you over-using memory, CPU, Disk I/O and considering efficient memory management strategies like object life-times and sizes? These are the kind of things you need to look into on the back-end.
Memory is not just a back-end thing; it’s also becoming more apparent on the front-end too. With the advance of JavaScript frameworks, people tend to leave objects open without clearing them down. Leaving a front-end JavaScript heavy application open in the browser for a long period of time can really eat up memory (some people leave browsers open for days, maybe longer).
Speaking of back-end and front-end, what IDE or code editor do you write your software in? Do you use Visual Studio for front-end and back-end, but what if you don’t have access to Visual Studio? Do you use ScriptCS for back-end and Sublime/Atom/brackets or even Visual Studio Code for the front-end?
Now that you have considered how you will build out your back-end, it’s time to decide on how that data will be stored and retrieved. There is a whole breadth of database technologies available to choose from with paths down NoSQL, relational or even caching to choose from.
If you choose to take the NoSQL path, you then need to consider whether to use a Key-value store like FoundationDB or a document store like MongoDB or even a graph DB like Neo4j. If however, you’re more of a relational DB Dev, you can choose the likes of MySql, PostGreSQL, MSSQL Server etc. Alternatively, distributed cache based stores can be quite useful if your data doesn’t need to be persisted for long periods of time, with the use of Redis, AppFabric or Memcached.
Knowing which technology to choose for your app is one thing (and having a deep understanding of your domain model will greatly attribute to the choice you end up making), you will then need to consider how the client, or in your apps case, the back-end layer will communicate with the DB. Whether the client API for that DB is mature enough to take into consideration your business logic needed to store and retrieve data efficiently. You will also need to take into account efficient use of the data in the database. Considering the use of indexing strategies like clustered or non-clustered indexes in SQL Server or hash and range based indexes in MongoDB. Sharding is something you will also have to take into account in MongoDB or Normalisation, Vertical and Horizontal Partitioning in SQL Server.
If you are using an ORM on your back-end, performance will be a major consideration; you will have to be wary of the SQL statements that get generated by the ORM. The ORM may be creating many joins, profiling becomes key here and knowing how to monitor and profile SQL script executions on the DB. How you write your Stored Procedures or triggers on SQL Server for example is important, going back to the ORM point and returning only the right data and being wary of many joins or even temp tables. Knowing how to use the execution plan or use of external tools like SQL Sentry Plan Explorer will become useful here. Like the previous layers, testing is also important at the database level and knowing what to put into your stored procedures and what to put into your back-end in terms of data retrieval, addition and manipulation can sometimes be the hard bit. And deciding what business logic is truly and what is data logic will help guide how you construct your tests.
Of course you can’t just delve straight into development without considering the overall landscape of your application. A lot is being said lately about the use of micro-services. But, micro-services are not for everyone and are sometimes considered for the more mature application whereby everyone already understands the domain model. If you don’t quite understand your domain model, then a micro service is not for you. Sometimes the old style layer cake approach is perfectly acceptable. If not, you can use the CQRS approach and make use of messaging technologies like EventStore, RabbitMQ, TIBCO EMS or Azure Service Bus depending on your needs.
If you believe parts of your application will become discarded quickly as the app evolves, you can take a sacrificial approach. This could be an Octagonal architecture where each component doesn’t know of the existence of the other components and you can easily and quickly remove and replace the components you don’t need without affecting the other components. There is certainly a lot to consider on the architectural landscape.
Next up, whatever way you have architected your application will affect how you get changes into production for your customers or clients to use and see the value of your work. This is where CI/CD (Continuous Integration and Continuous Delivery) becomes a key component with how we isolate and deploy our application quickly and efficiently. How do you achieve this? This can be through the use of tools like Jenkins, AppVeyor, TeamCity, Go, Octopus Deploy, PowerShell etc. Also, the CI/CD of our databases can become very important in application and DB isolation and how we consider how this can be done. Whether to use a state or transformational model, leading to use of tools such as RedGates SQL Compare or DBUp.
But where does the source of your application and DB live? Do you use a distributed version control systems like Git or do you use a centralised model like SVN. Automation is important and with CI and Continuous Deployment, testing will factor in heavily in all environments leading up to production. So it will be important that in your development of the application that you have written tests to cover areas such as, unit, integration, acceptance, throughput, capacity, security and penetration testing.
Understanding all areas of automated testing is one thing, it’s also about knowing how to provision environments to accommodate the levels of testing. Use of CM (Configuration Management) tools such as Chef, Puppet, Ansible, Desired State Configuration or GaurdRail and treating the CM as code and versioning it. Also, what infrastructure are you actually going to use? Is it going be Linux or Windows or is it going to be containerised on something like Docker? Are you going to use IaaS, PaaS, SaaS or even FoaaS? What will the system and network topology look like? Knowing the Von Neumann architecture for your system will be one thing. You will need to know the IO of the system you are setting up in terms of software, internal and external (or virtualised) hardware and how communication happens between all these parts.
Use of CI/CD is becoming mission critical these days for devs with ops knowledge, but this all adds up to the overall goal of ops and dev, feedback. Feedback gives us the sugar coated happiness we need, to know we are adding value to our end user. Feedback also gives us the ability to change, and how quick we get that feedback results in how quick we can get that change in.
Measuring value in terms of end-user happiness is one way of gaining quality feedback, but measuring IT performance is yet another. Understanding what kind of feedback we need, can be achieved through the use of monitoring tools like NewRelic or Datadog, or auditing from our applications with the likes of Nlog or Graylog. Also, how do we do profile and what profiling tools can we or should we use, for example; dotTrace or perfmon. But then you need to take into account what their impact in terms of individual overhead they can bring in the environment they are run against. Knowing the right tools for the previous points becomes essential in monitoring, auditing and application logging. Performance information will be an essential investment and can be measured in terms of throughput with number of releases per day and less reliance on support.
It’s worrying when you consider some of the big names who have been hacked recently due to various reasons, for example, take a look at the most recent Sony Entertainment attack or the Adobe exposure from a couple of years ago. Knowing the various attack vectors in terms of the OWASP top 10 principles for security will only get you so far, but should be enough to get your application secure if it’s mostly a web based application. But you also need to take into account the various compliance models like PCI if you are working with credit card transactions. You need to understand how to secure your user management system and how your private data is sent across the wire with use of OAUTH and the TLS level in place with the strength of the encryption algorithm used in the transfer of such data.
Hacking is becoming a way of making money these days with the use of Ransom-ware. Security is becoming a big part of development and it’s something that a developer needs to be very wary of. Especially with the advancement of the maker movement and IoT and how secure that can be and some of the common vulnerabilities developers need to take into consideration, but that’s a topic for another day.
Of course, you can’t start any kind of development unless you know what your requirements are. This very crucial stage requires the developer (applying principles like INVEST) to be able to understand and granulise if need be, the story that needs to be worked on. From this, the developer will need to help understand and gather the further requirements in terms of functional and non-functional. This is to help guide some of the previous areas discussed such as security and what type of system architecture will need to be put in place.
But how do you facilitate this process if you are working with Agile? Do you use SCRUM and become a Scrum Master and know how to use and administer the various project management and tracking tools available such as Jira or Trello? This shouldn’t be necessary but it will help with understanding and communication of the various processes involved. For example; stand-ups, product backlog grooming, retrospectives, sprint reviews, show and tells, measuring burn down and velocity, and knowing when and how to effectively shield from scope creep.
What’s the right culture?
Being at one with how your culture and how your team and teams around you work is another aspect of consideration. Looking at how we effectively communicate with all members around us, applying techniques like the learning conversation (link to the learning conversation blog entry to go here when it is published on the tech blog) and humility respect and trust in our interpersonal relationships. There is also something of a movement towards a DevOpSec culture now, where the developer will work with and make considerations for ops and info sec when constructing applications. So, it truly is difficult to try and keep up with all these aspects that affect the development of applications. With knowing the current leading ways to solve problems or even realising that some of the old techniques might still be better for your use case.
Was it always difficult?
Speaking of old techniques, if you look back about 10 years ago, if you ask me, things were a little easier. You didn’t have all these JavaScript frameworks popping out of the ground. There weren’t as many back-end frameworks to choose from. Developers defaulted to relational databases. Cloud wasn’t really a thing.
More and more people are becoming tech savvy and are online nowadays, whether that’s through their pc, laptop, phone, watch, Fitbit or toaster. The industries are looking at new ways of reaching customers through the medium of the internet. This is creating more problems when we deal with scale and applications falling over because of this. So there are more and more ways coming out to solve these kinds of problems. Can you really be on top of all the development trends and aspects in terms of knowing the leading ways to solve problems?
Is the T-Shaped Developer the answer? But what is a T-Shaped Developer?
This is someone who has expertise in one particular field such as databases and specialises in this. But also has an understanding in all other areas mentioned above. This allows the developer the opportunity to collaborate across disciplines, but make the decisions when it comes to implementations involving database work. This kind of developer is also known as a generalising specialist. Focusing on being a specialist in one particular area will allow a developer to gain the confidence that may be required to do consulting gigs, where specific expertise is needed. Or present talks at user group meet-ups or conferences on a particular subject to do with the field of choice. If the T-Shaped developer is really the kind of developer we should aspire to be, then shall we be looking for T-Shaped developers and should we be selling ourselves as T-Shaped developers?
But how far do you go on the vertical, as a T-Shaped developer? If you specialise with back-end development for example, should you need to know about memory management? Should you be able to spot memory inefficiencies on the heap or large object heap when you are writing managed code where the Garbage Collector will take care of this? Or is this a concern for someone who specialises in Ops? I guess this could even lead to a Sword Shaped developer (you read it here first), whereby the developer can reach a point and know when or where to stop in depth of knowledge on a particular field, as another specialist role would cover those areas.
I’ve only really tried to scratch the surface on all the areas involved in the development of applications, there is so much more to cover. So I’m sure you the reader may have other aspects that should be covered in one particular area such as front-end development for example. But this has been the purpose of this post to outline what I think are just some of the things developers need to consider when working as a full stack developer.
So… you’ve been tasked with building that funky new CMS, where shall you start?
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
Ian Barry 
Reblogged this on malickmbaye.
LikeLike