Being a Smart Full Stack Engineer

by Sysco LABS Blog 25 May 2016

Good developers should be familiar with the entire stack and know how to make life easier for those around them. To be a full-stack developer means to be someone who is comfortable working with both back-end and front-end technologies such as databases, Java, HTML, CSS, JavaScript and everything in between – even converting Photoshop designs to front-end code.

In this Innovation Session, Dinidu De Silva from the Software team talks about what it means to be a smart full-stack engineer. The session covers group product review, how to back up decisions, being nit-picky about a PR, and the concept of Codeship (continuous delivery).

Software developers work mainly around the field dealing with server side, data, front-end, deployment, HTML/CSS and UX. Full stack engineering is not exactly a new concept, but in Sri Lanka, most IT professionals are specific to one or a specialized set of technologies with only rudimentary knowledge in other aspects of the stack. Getting to know how a product fits the user and how it works is crucial. For instance, when coding the product’s UI, instead of asking, “What technological stack are we going to use for this?” we need to ask “For whom is this built for? How user friendly is it? What is it’s purpose?”.

A product retrospective is a necessary step towards building a better product. This needs to be carried out with a combination of developers, product engineers, UI engineers etc as everyone needs to have a good idea who the real stakeholders are. When carrying out a product retrospective the pain of the end user must be felt. This also means that a developer should not make rash decisions or be irrational without capturing proper data and analytics. After the data is gathered and the required analysis done, the developer can decide if a certain requirement is viable to do or necessary In terms of functionality of the product. Then the solution has to be brainstormed to test if this is how it should be functioning and if it does exactly what the user wants it to do. Afterwards it is up to the developers to come to a common consensus with the UI/UX engineers as to how to modify the user experience for the end user.

When carrying out a pull request review for the product, the golden rule is to commit small and commit often. Making the pull request for 40-60 files will make it harder for the code to be reviewed. It is advised that the code not be reformatted as it will make any GIT tools recognize the changes made, so it will change the entire format of the code. In a performance review, it is good practice among full stack developers to always make counter arguments when necessary to justify what has been done, and for what reasons. It is also necessary for one to critique their code themselves so it results in better quality. Full stack development should head in a direction based on continuous delivery rather than continuous integration as the products are delivered by the commits.

The deployment of software is not supposed to be arduous. Deploying software should be easy and could be done by any team member regardless of experience. Dinidu demonstrated how easy it is to set up a deployment pipeline from committing code, getting the automated tests run, and finally deploying the artifact through CodeShip. The whole process of kicking off Continuous Delivery was done within 20-30 minutes. From CodeShip code can be automatically deployed to production merely by merging development branch to the production branch by any developer.



Leave a Comment