Four Months of Software Engineering

17 Dec 2020

Intro

Gaining insight by experience cultivates a pool of experience and only the dawn can reveal what you’ve gained. Four months of Web Development using software and utility libraries I didn’t know even existed fostered by growth from knowing absolutely nothing about basic html, to creating page components using lodash, meteor, react, mongoDB, and cmd prompt to create a internal server for testing really does have a huge impact.

Development as a Team

Project Management is a must in situations where you have a team because everyone has there own ideas on where to go in the project, but by creating a project board with all the current issues we manage to narrow the focus on to which is more important at the time. Also, the organization is there to ensure that people don’t work on things that overlap with another person’s development, thus wasting time on unnessesary work. Meetings also need to happen atleast every week or 3 days to ensure that everyone is on the right track, issues with development can be resolved by others who know more, and if huge changes in development arise the team can adapt by focusing their resources on other more intricate and alarming issues.

Narrowing Issues to Make Help Easier

Nothing is more annoying than when people just say: “damn this code just does not work” and they show you an entire page of code which takes time to decipher and can even fustrate you with how it’s coded without explanation. Not only can you not resolve it yourself, but it’s a good chance nobody would be willing to resolve it themselves. The problem is too vast, there’s too much to read, too much to comprehend. Although you can’t understand why something doesn’t work, you can create a few mini test codes that would show you certain data that can narrow the issue down to a certain single issue that you don’t know the answer to. Then when you narrow it down to a single issue, not only does your depth of knowledge increase, but you also make the problem so easy either you can find it out on a forumn or you could just ask someone and they could give you the answer off the top of their head. In this way asking the question of “how do I fix this?” becomes something would won’t drive people insane with.

UI Frameworks

Raw HTML is the absolute worst thing to develop with, but it seems like every video out there all develop with raw HTML. What happens is that they create the absolute longest code in history, and we are talking about 100 lines with comprehensive knowledge on every single variable in style.css, for such simple things. The insanely long process starts all over again once they hit a new project. HTML on it’s own isn’t very pretty and takes time and comprehension to be able to understand how to create sleek designs. Using a utility library could solve these UI Issues instantly by using a single line of code to create a beautiful modernized website.

The libraries of choice were a great number and all for different things such as UI, data storage, data transfer, etc. However, the main one was Semantic UI (React). User Interface must be easily readable, simple, intuitive, and not look any worse than any other modern website out there; and this library fit all my needs. There’s so much convenience in it that you really don’t want to touch raw html again because of how unintuitive raw html feels.

The Fallacy of Expectations and Accomplishment

Often times I would overestimate what I could do just because it seemed extremely possible at the time stacking on piles of work to be expected for completion in a certain amount of time. Yet, it wasn’t through actual development did I realize how much errors I would get through the restrictions and formats of each utility library I used. A problem can seem simple yet be decievingly difficult. Logically all you have to do is create a form then connect a few variables to get an automated form to work, yet any other data format than a simple 1-depth array would be unusable. Sifting through so many answers that you begin to make more issues than you initially had seems to be the true pain of a programmer. To grow it’s important to underestimate what you can do to set a limit based off of your action. Ambition is good, but in a situation where development has to be pushed back because of slow accomplishment, only disapointment for the users and the development team ensues.