Continuing Thoughts On Software Engineering
12 May 2021
Right Knowledge, Right Environment, and Right Professor
When registering and reading the course catalog about software engineering, each person will create an idea of what the course would entail and some worries on what to expect. I for one, when I signed up for the software engineering course had created in my mind some thoughts on what the course could be about and naturally I was a little worried. I went into the course assuming that it will be another course that is code intensive, and for the first few weeks my assumptions were correct. We were coding using "if" statements, I even remember having to do Fibonacci numbers, and I'm like thinking "alright here we go, it's about to get intense". However, as the course continued and everyone started to get into the groove of things, it started to get easier. Don't get me wrong the course still involved coding and a lot of it most of the time on many different pages, but I can attest that it wasn't at all bad. Granted there were a lot of new things to learn also, but we will get to that a little later.
The modules were set up to build one on top of the other and you start learning things and getting excited for things and it became more enjoyable to me. You start to learn about development environments, coding standards, configuration management, and a slew of other relevant things all related to software engineering as a whole, without you even realizing that you were learning an in-depth subject, which made it so enjoyable. I truly believe that what contributed to the enjoyment about learning software engineering in general had to do with how the material is laid out for you to be able to absorb all the knowledge you were taking in, the environment into which you are learning, and of course the professor to chart the course. Software engineering in general is a multifaceted subject and could on some occasions seem overwhelming but given the right knowledge, right environment, and right professor it becomes something you love to do.
Software Engineering Uses Many Different Environments
Software engineering uses many different versions of development environments. First, a development environment is an integrated development environment, which is a software development tool the has the following properties:
- Language-aware editing
- Project definition facilities
- Integrated compilation
- Integrated stepwise execution
in other words an IDE is where a software engineer will do the majority of their work when it relates to the creation or edits of a software program.
As a software engineer you will encounter many many many different environments way before you even graduate. The way a software engineer decides on which environment to work with comes down to a few factors. The engineer may have encountered a particular environment based on the preference of a professor, the type of job they are working on, or just personal preferences. Not all IDEs are created equally so when it boils down to it, we tend to stick to what we know and what we know is the easiest. For example, I have been introduced to many different IDEs through out my career in school and sometimes I have to work with IDEs because that is the only available IDE there is for a job to get done, other times i'm introduced to a environment because that is the preference of the instructor to help even out the playing fields in terms of other student experiences. I don't mind working in any environments, to me it helps me be a better software engineer and allows me to be more marketable because I have gained experiences in many different forms of IDEs compared to someone who hasn't.
Visual studios is my preferred language to code in, till this day I remember how I was introduced to it. We were in a lab class and I couldn't figure out and was not mentally prepared to work and code in a terminal, for some reason my head just could not wrap around the idea that to compile a code and to link a code I would need to enter a super long command line prompt, I was in shock that there wasn't a magic button in where i would click it and it would do all the work for me in the background, little did I know that the single button was technically doing the same thing. My lab partner noticed how much I was struggling in working within the terminal environment and using VI as my editor. That is when he introduced me to Visual Studios, he showed me very quickly how to work around it and do the work that needed to be done and not have to rely heavily on the terminal. It was heaven and it made my life much better. In the beginning it was rough but I stuck through it because I didn't want to go back to the alternative and work in a terminal environment again. However, here we are years later and it's still my preferred choice of development environment because I understand it and I'm comfortable with it.
Everytime I have to work in a different environment I would first check to see if I could do my work within Visual studios and if I couldn't that is when I would work in another environment, I'm not totally closed off to other environments just because I have a preference. I completely understand that there will just be instances in which Visual Studios just can not work and I'm ok with that.
A development environment goes beyond web development. I feel like a web development environment such as the use of JSfiddle and intelliJ is part of a small picture that helps build a bigger picture. A development environment even goes beyond the use of IDEs, to be a development environment, is an environment that you work in that will allow you to get to your full potential and nudges you in the write direction if you have any errors. Lastly, a development environment is an environment (to me) that you are most comfortable working in.
As a software engineer you will encounter many many many different environments way before you even graduate. The way a software engineer decides on which environment to work with comes down to a few factors. The engineer may have encountered a particular environment based on the preference of a professor, the type of job they are working on, or just personal preferences. Not all IDEs are created equally so when it boils down to it, we tend to stick to what we know and what we know is the easiest. For example, I have been introduced to many different IDEs through out my career in school and sometimes I have to work with IDEs because that is the only available IDE there is for a job to get done, other times i'm introduced to a environment because that is the preference of the instructor to help even out the playing fields in terms of other student experiences. I don't mind working in any environments, to me it helps me be a better software engineer and allows me to be more marketable because I have gained experiences in many different forms of IDEs compared to someone who hasn't.
Visual studios is my preferred language to code in, till this day I remember how I was introduced to it. We were in a lab class and I couldn't figure out and was not mentally prepared to work and code in a terminal, for some reason my head just could not wrap around the idea that to compile a code and to link a code I would need to enter a super long command line prompt, I was in shock that there wasn't a magic button in where i would click it and it would do all the work for me in the background, little did I know that the single button was technically doing the same thing. My lab partner noticed how much I was struggling in working within the terminal environment and using VI as my editor. That is when he introduced me to Visual Studios, he showed me very quickly how to work around it and do the work that needed to be done and not have to rely heavily on the terminal. It was heaven and it made my life much better. In the beginning it was rough but I stuck through it because I didn't want to go back to the alternative and work in a terminal environment again. However, here we are years later and it's still my preferred choice of development environment because I understand it and I'm comfortable with it.
Everytime I have to work in a different environment I would first check to see if I could do my work within Visual studios and if I couldn't that is when I would work in another environment, I'm not totally closed off to other environments just because I have a preference. I completely understand that there will just be instances in which Visual Studios just can not work and I'm ok with that.
A development environment goes beyond web development. I feel like a web development environment such as the use of JSfiddle and intelliJ is part of a small picture that helps build a bigger picture. A development environment even goes beyond the use of IDEs, to be a development environment, is an environment that you work in that will allow you to get to your full potential and nudges you in the write direction if you have any errors. Lastly, a development environment is an environment (to me) that you are most comfortable working in.
Coding Standards, its not just an Option, but the Rule of the Land
Coding standards are important it helps improve the readability by ensuring a common look and feel from one area to the next, it also helps detect and remove basic anti-patterns or generic coding mistakes associated with a language or library, and if there is only one thing a software engineer should do, it should be to ensure that their code quality is up to coding standards. I for one am very thankful for having coding standards ingrained and etched in my mind so much so that it has become second nature and it's something that I don't really think about anymore, I just sort of do it. With that being said and I have stated prior, each language, has their own version of coding standards and it's always a good idea to be open to them, but the great news is most development environment will most likely come with a standard checker, for example, in IntelliJ we religiously used eslint. The really nice thing about having a coding checker is that if you did make a mistake not only will it point it out for you but will on occasion fix it for you automatically or you can choose to fix the error manually. IntelliJ will allow you to do both, on the other hand, in Visual Studios if you are coding in C or C++ uses their own form of eslint.
Coding standards are very hard to police, you don't even get a fine if you do not adhere to some form of coding standard. The worst that will happen is your fellow peers would choose not to want to work with you, you might be talked about, or worse get angry at you because no one would understand or they may find it hard to read your code, which in turn you could run the risk of being a social outcast within your own community. Running the risk of being a social outcast in your community does a pretty good job in enforcing the coding standard in a professional setting and that would warrant enough to have any software engineer follow a coding standard. Luckily for us we live in an age in where there are tools that help us and enable us to quickly adhere to the coding standards which are mentioned above. Therefore, there shouldn't be any excuse not to abide by a standard.
Software engineering is a civilized community and we adhere to many different standards, such standards could come in the form of ethics, inclusion, or coding standards. These habits are taught to an individual at the very beginning and are built upon as the years passes, it is heavily ingrained into our DNA that it becomes a part of us. It's like who we are as software engineers without some form of standards. Coding is a language and just like any language it has to and must have standards. For this, I have learned that space, placements, brackets, parenthesis, and anything in between must be placed in its proper location so that anyone reading the code that we write could understand it. Consider this, if you were to read a sentence in english and during that sentence a random spanish word is placed in that sentence, as the reader you would most likely question it, wondering what the heck happened, and probably laugh at the person who wrote that sentence for the error. In the end, coding standards are something I learned a long time ago, but sometimes it's nice to be made aware of it every so often to further help strengthen the habit. I foresee that I will now and forever continue using coding standards in my future and it will be something I will not easily omit from my memory.
Coding standards are very hard to police, you don't even get a fine if you do not adhere to some form of coding standard. The worst that will happen is your fellow peers would choose not to want to work with you, you might be talked about, or worse get angry at you because no one would understand or they may find it hard to read your code, which in turn you could run the risk of being a social outcast within your own community. Running the risk of being a social outcast in your community does a pretty good job in enforcing the coding standard in a professional setting and that would warrant enough to have any software engineer follow a coding standard. Luckily for us we live in an age in where there are tools that help us and enable us to quickly adhere to the coding standards which are mentioned above. Therefore, there shouldn't be any excuse not to abide by a standard.
Software engineering is a civilized community and we adhere to many different standards, such standards could come in the form of ethics, inclusion, or coding standards. These habits are taught to an individual at the very beginning and are built upon as the years passes, it is heavily ingrained into our DNA that it becomes a part of us. It's like who we are as software engineers without some form of standards. Coding is a language and just like any language it has to and must have standards. For this, I have learned that space, placements, brackets, parenthesis, and anything in between must be placed in its proper location so that anyone reading the code that we write could understand it. Consider this, if you were to read a sentence in english and during that sentence a random spanish word is placed in that sentence, as the reader you would most likely question it, wondering what the heck happened, and probably laugh at the person who wrote that sentence for the error. In the end, coding standards are something I learned a long time ago, but sometimes it's nice to be made aware of it every so often to further help strengthen the habit. I foresee that I will now and forever continue using coding standards in my future and it will be something I will not easily omit from my memory.
Getting Comfortable With Configuration Management
Let's start off with a story. I'm a Computer Engineering Student who belongs to the College of Engineering, and as an engineering student every student is required to be part of a sophmore, junior, and senior project, to which they are all graded. These projects could be the choice of any students and are meant to help put into practice what the student has learned so far into real world applications. The project classes aren't listed on the schools website and it's the students responsibility to attain the course number from the professor managing the project. For my junior project, I was shopping around, asking friends what projects they were in and if they liked it. One day I asked a friend in class about the project that she was doing and she mentioned she was a part of Team Kanaloa. Team Kanaloa is a team of engineers in different fields who come together to enhance, maintain, and complete an unmanned marine vessel. Once my friend mentioned it I was all in I was super stoked to work with the team, so I joined. My task for the team was to design and draw the circuitry of the vessel and maintain its batteries. Throughout the time we were working with github (uploading new schematics, downloading code, and other things related to the optimal health of the vessel) and I had no idea what github was about or what its main purpose was, I thought it was just a site for us to unload our code onto. To be honest I had no idea how to even work the site, my greatest fear is I would delete something by accident and wipe all the team's repository. It was a nightmare. I tried researching it, watched videos, caught up on any tutorial but nothing really flowed with me. I ended up not returning to the team for my senior project, having to work with git and not understanding it left a bad after taste in my mouth.
Fast forward a year, and I'm taking the required software engineering course. I was just cruising along enjoying my time and learning. Then we got to the Configuration Management module, at first I wasn't too concerned, and then it happened, I heard "github". As soon as I heard the "github", my mind went back directly to my days with Team Kanaloa and automatically I was dreading the module. I pushed forward because I needed to pass the class all the while I kept waiting for the other shoe to drop. However, something interesting happened, the shoe never dropped and I understood the whole concept of configuration management and all of my questions during my days with Team Kanaloa started getting answered, it was amazing, it's as if a light bulb turned on in my head.
Who would have thought that given the right knowledge, right environment, right professor would take away all those fears. All it took was someone to explain the process behind the product and practicing using the product in an environment that a solution was given in the event you get stuck, and all the supporting materials to read up on to further your knowledge for it to click. Basically, systems exist in multiple configurations and for many different platforms. Configuration management is the attempt to identify and track all relevant elements of the configuration of a system, so that all possible errors can bi identified and possible solutions can be found and which version control i.e. github plays a hand into. Different members of a team can all have one singular copy of the master code and each team member is able to make edits on the master code in a separate branch locally on their systems without the threat of over-writing the mast code and when it's ready to be merged the user is able to do so. If an error is found during the merging of the member branch they will be notified. That is what github basically does and after learning all that and understanding it using github isn't a nightmare anymore, it's a need and for that I will always be thankful for that module and I will take that with me into any future project I may be in.
Last note, I found another team called the RED-Lab team in which we were responsible for creating a camera system to think for itself on deciding what is a Coconut Beetle and what is not and send those images to the teams server and all that was used with github to which I introduced the team to all because of my software engineering class.
Fast forward a year, and I'm taking the required software engineering course. I was just cruising along enjoying my time and learning. Then we got to the Configuration Management module, at first I wasn't too concerned, and then it happened, I heard "github". As soon as I heard the "github", my mind went back directly to my days with Team Kanaloa and automatically I was dreading the module. I pushed forward because I needed to pass the class all the while I kept waiting for the other shoe to drop. However, something interesting happened, the shoe never dropped and I understood the whole concept of configuration management and all of my questions during my days with Team Kanaloa started getting answered, it was amazing, it's as if a light bulb turned on in my head.
Who would have thought that given the right knowledge, right environment, right professor would take away all those fears. All it took was someone to explain the process behind the product and practicing using the product in an environment that a solution was given in the event you get stuck, and all the supporting materials to read up on to further your knowledge for it to click. Basically, systems exist in multiple configurations and for many different platforms. Configuration management is the attempt to identify and track all relevant elements of the configuration of a system, so that all possible errors can bi identified and possible solutions can be found and which version control i.e. github plays a hand into. Different members of a team can all have one singular copy of the master code and each team member is able to make edits on the master code in a separate branch locally on their systems without the threat of over-writing the mast code and when it's ready to be merged the user is able to do so. If an error is found during the merging of the member branch they will be notified. That is what github basically does and after learning all that and understanding it using github isn't a nightmare anymore, it's a need and for that I will always be thankful for that module and I will take that with me into any future project I may be in.
Last note, I found another team called the RED-Lab team in which we were responsible for creating a camera system to think for itself on deciding what is a Coconut Beetle and what is not and send those images to the teams server and all that was used with github to which I introduced the team to all because of my software engineering class.
Final Thoughts
Closing thoughts, although software engineering dealt with many web development tools throughout the course, there are many other aspects to the course that has strengthened my habits, helped me understand gray areas, and introduced me to other development environments. The one thing I'm most thankful for and am excited to use outside web development is configuration management and version control allowing me to work extensively within the github ecosystem. I will carry that throughout my career as a software engineer. My assumptions going into the course have been put to rest and left excitement for the future moving forward.