DEV Community: Corey McCarty

Hacktoberfest

Corey McCarty — Wed, 06 Oct 2021 00:00:00 +0000

What is Hacktoberfest?

Hacktoberfest is an effort by Digital Ocean to increase involvement in Open Source projects. Sign up here.

What is Open Source?

Definition

Open source is source code that is made freely available for possible modification and redistribution. Products include permission to use the source code, design documents, or content of the product. The open-source model is a decentralized software development model that encourages open collaboration. A main principle of open-source software development is peer production, with products such as source code, blueprints, and documentation freely available to the public. The open-source movement in software began as a response to the limitations of proprietary code.

It's commonly pointed out about open source that it's "Free as in freedom, not as in beer".

Projects can be big or small, and developers free or paid. Any software project can be made open source by adopting an appropriate license and allowing public contribution.

Examples of proprietary or closed source software

Microsoft Windows
iOS
Oracle SQL Server
Java programming language

examples of open source software

Linux
Wikipedia
Firefox
Chromium
pip
npm
Go lang

FAQ

Why is open source software important

Because open source software has freely available source code, if the maintainer ever stops providing updates (or closes the source after a certain point) then the community can take the source and continue development of it.

Why is contributing to open source is important, and what do I get out of doing this FREE work?

Learning is important, and it can be difficult to learn about long term software maintenance in a small single person project. Working on open source software allows you to step into long term support of software even before having a job in the field. You need to read through the docs and figure out what's going on before you can contribute. This is VERY much like what happens in the real world.

Also, if you have issues with the software then you can go and make a fix yourself instead of waiting for the maintainer to schedule and write the change.

What is the most minimal thing I can do to contribute?

Contributions can be any submission to a code repository. It can be to the code itself, tests, build process, or even documentation. It can also be quite valuable to larger projects to even have someone that will ask clarifying questions in new issues.

How are my contributions tracked in a way I can get the swag?

You Register with Digital Ocean at the Hacktoberfest website.

Where can I contribute at (I don't understand GitHub)?

If you go to the resources section on their webpage there are resources for contibuting no matter your level. There are ways to search for repositories in Github and GitLab. Dev.to has a topic and there is discussion on Twitter. This is one of the few events that manages to permeate throughout dev culture.

I don't know how to download the codebase so I can contribute?

Free Code Camp - Git Guide

How do I find the issues to be fixed?

Issues are listed on Github for a given repository. You can also use issuehub.pro

Who do I talk to in a codebase to make sure I'm doing it correctly?

This will vary pretty widely depending on the project. There will usually be some type of information on the project's README.md and often a CONTRIBUTING.md

Summary

How do I contribute?

Register
Make 4 PR's
Get shirt (or have a tree planted in your name)

If you'd like to find more open source software to use checkout SourceForge

Pitching Ideas to Developers

Corey McCarty — Tue, 21 Sep 2021 00:00:00 +0000

There's a trope among developers of the people that have a "great idea" for an app or website, but no coding skills or knowledge. It's quite common for those people to come to a developer or community looking to find someone interested in putting in the work of creating the thing that they envision. Most of the time it comes as a startup pitch where they expect the developer to put in work with no promise of ever receiving payment. This is basically asking someone to work for free on the gamble that there will one day be more income than the cost of infrastructure. Many developers tend towards a skeptical or cynical reaction towards this. There was even a whole plot point in the show Silicon Valley about it. One developer's reaction can be read here

I'll share with you some of the information that came out in one such conversation.

Think of this like a startup

If you were starting any other type of business than tech you would put together a specific plan before bringing in any other people. Consider "I have an idea for a business" and put effort into modeling out, describing, and planning how your business works and get lots of feedback.

If you had a restaurant idea and went to a chef saying "I have an idea for a restaurant, but I can't cook and I'm looking for someone to handle the kitchen part." You had better have a strong business case for why a chef would want to invest their time in your idea.

Planning

There are lots of things that you can plan out without a developer or writing any code at all. You can write the business cases(s), draw out the screens in all sorts of user friendly tools (or on paper), get feedback from potential users about what features they would want, etc.

When you come to the point of sitting down with a developer, then you would be handing over a bunch of specifications and they can just build it. The best way to do this would be to have some amount of money to invest to pay the developer to deliver a some bit of the product, This is exactly like you would do if you were prototyping a physical invention.

More often than not, devs find that when/if they get involved with this type of thing they aren't just developers they're also expected to be designers, marketing, search engine optimization (SEO) experts, and product managers. Suddenly they are doing the work of a whole team (or more) with no promise of ever being paid.

Takeaway

You may very well have an amazing idea and find the perfect developer that both believes in the idea, and has endless free time to devote to it, but keep in mind that what you're asking is basically "I had this idea in the shower that I've put no effort into and I'd love for you to spend all of your spare time building this thing for me so that I might be able to make lots of money without doing anything." If you've put in lots of effort and have a well laid out plan for this company that you are starting, you are much more likely to find a developer that's interested.

Special thanks to George Spake for assisting with this content.

Coding Challenge with Clean Code

Corey McCarty — Fri, 20 Aug 2021 00:00:00 +0000

After studying Uncle Bob's Clean Code and trying to practice it as much as possible, I find that it can make a huge improvement to the maintainability or even just readability of a piece of code.

This coding challenge came up in one of my favorite coding communities:

Length of the Last Word

Given a string s consisting of some words separated by some number of spaces, return the length of the last word in the string.

A word is a maximal substring consisting of non-space characters only.

So, because I like to do challenges with tests, I put together this bit of unit test using Python's built in unittest package based on the three examples that were given with the challenge.

from unittest import TestCase
def last_word_length(input_str): 
    pass
class TestLastWordLength(TestCase): 
    def test_one(self): 
        assert(last_word_length_golf('Hello World')) == 5 
    def test_two(self): 
        assert(last_word_length_golf(' fly me to the moon ')) == 4
    def test_three(self): 
        assert(last_word_length_golf('luffy is still joyboy')) == 6

Now, I knew that I could pull this off with a single line of Python. I quickly wrote this:

import re
def last_word_length(input_str): 
    return len(re.split(r'[\W]+', input_str.strip())[-1])

This does everything that the challenge asks for, but part of the goal of doing these challenges in my community is that we use several different languages and it allows everyone to get more familiar with the language that you used, whether they have ever written it before or not. One liners like this are not usually a good idea for long term maintenance OR teaching. So, I took a minute to clean it up a bit. Having tests laid out made it really easy to know that I'd not introduced any errors.

import re
def last_word_length(input_str): 
    indefinite_whitespace = r'[\W]+' 
    clean_input = input_str.strip() 
    words = re.split(indefinite_whitespace, clean_input) 
    return len(words[-1])

Now, it's pretty easy for anyone with a moderate amount of coding ability to understand what's going on. We have a regex that matches any clustering of whitespace. We have an input string that gets trimmed/stripped of it's surrounding whitespace. That string gets split according to the regex. And then we return the length of the last word.

There are two main things that this technique improves. Breaking the pieces apart reduces the mental overhead of understanding each piece. Naming the variable helps to document the intention of that line. It also makes the later lines significantly easier to understand by offering those names. That benefit will help you both with the reading and the writing of your code. The other major benefit comes long after this code has been put into version control. The history of this code allows you to tell which part of this was changed when. Instead of a diff showing that something in this block was changed at a, b, c, and d commits, you can see that the regex changed in commit a, the input cleaning changed in b and d and maybe the split call changed in c. This is especially helpful if you have IDE/editor functionality that helps you to see the git blame info for each line.

Career Advancement

Corey McCarty — Thu, 10 Jun 2021 00:00:00 +0000

Once you have figured out a way into your first software development role, it is only logical that you would consider how you can move forward in your career. But it's not always clear what the next steps are beyond completing the tasks that you are given.

Learning

Firstly, I'd like to say that setting your focus on climbing the ladder quickly is not exactly the best use of your time. No doubt that you've figured out that learning is a pretty important part of our career field, and that doesn't change after getting hired. Having a job does provide a significant amount of direction for your learning. It's a good first step to get comfortable with the language, frameworks, and tools that your team uses; focus first on what's relevant to your current project. Learning things that seem small may be greatly helpful when making decisions later.

When you are learning your first language the biggest thing that you are really learning is what computer programming really is. You learn how a programming language can be used to complete tasks. When you learn your second programming language, then the most important thing that you are learning is how you learn best. You will also learn how much the learning of your first language carries over into using a new language. There should be significant overlap in techniques. The language after all is just a tool at your disposal. By the time that you learn your third programming language you are really learning how esily you can pick up new things. I highly encourage people to take languages one at a time. You will learn more by getting into a deeper knowledge of your first language than by trying to learn three languages at the same time (like one of my coworkers). Allow yourself to become fluent in your first langauge to the point that you can think in that language the same way that you would a spoken language. If for some reason you find yourself working in a new language before you believe that you have reached the necessary depth in your first language then you should work to bring that new language to the level of understanding that you had in your first language, and continuing in this new language from there.

Know Yourself

The biggest part of your career, throughout all phases of it, is you. If you are anything like me then you may have managed to reach a suprising age before actually understanding WHO you are, and what your strengths are. Branding is something that gets discussed a lot in some dev circles, and the short version is that you have to know what's important to you, and what you're good at. I highly recommend asking your coworkers that know you best what they think your strengths are. For me personally this is asking questions and just talking to people. I really enjoy learning about things, whether those things are relevant to my job or not. The thing that has been the central pivot of any acknowledgement that I've received are about taking part in discussions and asking questions that move towards goals. Your strengths aren't likely the same as mine, but it's very important that you know what they are.

Play to Your Strenghths

Once you know what things set you apart from your peers and where your largest amount of value lies, you need to keep these in mind during your work. For me this means that I make sure to ask questions about things that don't seem to make sense. Sometimes this reveals that I'm just the only one in the room that didn't know something, other times it reveals that the entire team had assumed something wrongly. If your strengths lie directly in code work then perhaps you would be able to provide special value in your code reviews or pair/team programming where you could make an impact with the overall code quality. Whatever you do with your streghths, remember that every person on your team also has some strength and you should never assume that you are better than they are.

Remember Your Team

The best engineers not only provide value in their work, but improve the skills of those around them. This comes in the forms of teaching and of motivating those around them to learn more. Developing a culture of improvement and learning is paramount if a team is going to get better over time. As learning is such a pivotal part of our industry a team/person that is not interested in improvement is a liability to their company as our tools continue to improve. Our languages get new features and flaws are discovered. If we don't grow with our tools then our productivity is actually reducing over time.

Advancement Path

In order to become a junior developer you need to learn how to write code. These are the basic skills that everyone in the field should have. I expect that everyone reading this understands some amount of computer programming basics and knows that it is the vocabulary that we use to discuss solutions.

In order to move on to a mid level then you need to understand the tooling itself and how tradeoffs work. Every tool has its strengths and weaknesses. As you work on different projects you will learn about the weaknesses of the tools that you use and the problems that can happen because of this. There is no such thing as a 'best programming language' or 'best framework'. Every tool has an area where it accels. Understanding tradeoffs is what will help you to move into this space.

As you move toward senior or lead, your skills need to spread more into team culture and dynamics. It becomes important that you be able to mentor other developers. Mentorship doesn't always imply that the mentor knows more than the mentee. We all have gaps in our knowledge and in my experience a mentorship relationship can actually go both ways. The developer that has been in the industry longer can provide direction from that knowledge, and the developer that's been in the industry less time can provide information about different practices or tools that the more experienced dev has no experience with. Being able to identify where your knowledge gaps are and who around you knows the most are very important. In order to make the important decisions that come with more responsibility and title you must be able to evaluate the necessary factors and this often means asking the people that have the most knowledge.

Uncle Bob - Lesson One

Corey McCarty — Tue, 18 Aug 2020 00:00:00 +0000

This material is a summary of a talk by Uncle Bob that I watched on YouTube

Regardless of age, race, gender as developers we share a passion for something, and can communicate about it in a way that most other people can't.

Introduction to Clean Code

In this comic the door on the right must contain some pretty terrible code with five simultaneous WTF's, but how do we move from that to the left with only two? How do we avoid driving coworkers mad trying to understand our code?

In the lecture room there are thousands of processors. Your smartphone alone contains more computing power than the the planet Earth in 1980. Computers/processors are in a huge amount of things around us. Airbuds, cameras, lights, speakers, smoke detectors, and even exit signs contain small processors. In speakers and microphones, a small audio processor is used for removing audio hum. It's become less expensive than using a traditional capacitor and inductor. Trickle charge in emergency exit signs is probably being monitored by a processor. Any given person in our society interacts with a software system at least once every minute. There is software running in your refrigerator, dishwasher, stove, tv, remote, and even your car. Modern cars run over a hundred million lines of code running in the entertainment system, gps, and even in the engine controller. When you push on the brake pedal there are if statements that decide whether or not to slow/stop the car. This means that there are likely dozens of people that have died because software controlling the brake and accelerator failed for some stupid reason.

Why?

You and I are killing people. We didn't get into this business to kill people. We became programmers because we had some experience with a cool machine somewhere that we were able to make do something fun, and we decided that we wanted to do that for the rest of our life. Now you can kill people with software, or lose 450 million of dollars in 45 minutes. There is nothing that you can do in our society without software. Society doesn't realize just how dependent everything is on software. And developers control that. The people that believe that they rule the world bring their rules to us and we write the software that governs the machines that actually run the world. Society doesn't yet comprehend how dependent they are upon developers. They won't until some dumb programmer does one dumb thing and kills 10,000 people at once. When that occurs the politicians of the world will rise up and point a finger at US.

The CEO of Volkswagen North America testified before the American congress about why their software was cheating EPA regulations in California. He said "It was just a couple of software developers that did this for whatever reason." It _ was _ a couple of developers that did it. They are now in jail. But when the politicians of the world come to hold us accountable for our actions they will ask "How could you let this happen?" and if our answer is "Boss said that it had to get done by Tuesday" then they will be forced to regulate us and tell us what languages we can use, what courses we must take, what books we must read, what process we must follow, and what signatures that we must get to do anything.

How do we avoid this? We avoid it by getting there first. We have to establish an ethics of software development. We are not a profession as there is nothing that we profess. We have to build our own set of standards so that when the politicians of the world come to hold us accountable we can respond with proof that it is not neglegence because we have standards, morals, and ethics that have been maintained. They will come to us to looking for those standards that they can enforce, and we had better have a good definition of what it is that we hold dear as a profession. One of those had better be cleanliness of code.

Why are Programmers so slow?

Kent Beck wrote a book called Implementation Patterns. In its introduction it stated that the book was based on a '_ fragile premise ' that ' good code matters _.' This seems pretty solid. If we work on a green field project with no existing code then we can get features completed extremely fast. By the time a year has past, a request for similarly sized feature may take six months. The speed at the beginning is done at the cost of a bit of mess. Over time this slows progress down to around 1% of the original rate.

You have to figure out how to go faster. Adding more people to the team makes the team slower. The experienced people have to slow down to train the new people, and you have to hope that the new peole come up to speed in time to become helpful. The new people then wind up being trained by the old code, and they emulate it. The problem of messy code becomes worse.

If programmers didn't make a mess then they'd be faster. You could add new features in a reasonable amount of time as long as the code was able to be maintained in an orderly way. We make the mess so that we can go fast. Then once the code finally works there can be a fear of breaking it that prevents it being touched again. Having gotten it work is only first part. Nobody writes clean code. Once it works it will be a mess. Once it works, it should then be cleaned. That should take roughly the same amount of time that it took to write it. Nobody wants to put that time in, and that's the problem. You aren't done when it works, you're done when it's right. With that attitude it would always stay clean and you'd never experience the slow down.

What is Clean Code?

Uncle Bob says:

The only way to go fast is to go well.

Bjarne Stroustrup - creator of C++

I like my code to be elegant and efficient ... clean code does one thing well.

But, what does "one thing" mean? Uncle Bob has a theory.

Grady Booch - writer of Object Oriented Software Design with Applications

Clean code is simple and direct. It reads like well-written prose...

What does it mean for code to resemble well-written prose? Uncle Bob's theory on this will be shared as we go forward.

Michael Feathers

Clean code always looks like it was written by someone who cares.

When's the last time that you read a module and thought that the author cared about you and everyone that would be reading that code?

Your job is only half to get code to work. The more important half of your job is to write code that other people can understand and maintain. Understandable code that doesn't work can be made to work, but working code that can't be understood will become useless as soon as the requirements change. It is more important to communicate with your peers using a programming language than it is for the computer to understand you.

Ward Cunningham - inventor of wiki

You know you are working on clean code when each routine you read turns out to be pretty much what you expected.

Very first wiki is still alive at c2.com and was built in 19 lines of Perl in 1990. It's full of desing patterns, extreme programming and agile stuff.

Everything is pretty much what you expect or ZERO WTF per second.

Analyzing some lines of code

Uncle Bob gives a few minutes to read and understand some example code that stretches across three slides and is far from being easily understood. The code is explained for handling his testing tool called Fitness which has tests defined on wiki pages. The code fetches setup and teardown pages for a test and creates html. TestableHTML is the function name which he calls horrible as functions should have verbs for names because they do something.

The first line of the function is creating a wiki page and the next is creating a string buffer which takes you crashing immediately from the highest level of abstraction into the lowest. Every line of a function should be at the same level of abstraction, which is one level below the name. We write code in a very rude way. We oscillate from high level to very low level as we think about things. There is nothing wrong with writing things this way, but you must come back and clean it up so that it can be easily understood.

The function follows four repetitions of the form: null check, page crawler, and three appends with one of the blocks having an extra append for a new line. Getting something done and then using copy and paste is common enough of a technique to follow for getting code to work, but not something that should be left.

Long code is not Good Code

A cursory cleanup of this code brings it into a single page where it becomes visible that the entire function body is enclosed in a single if statement. The control of that if statment has been moved into a boolean variable whose only purpose is to explain the state that it contains. if(isTestPage) reads more like well-written prose. The four similar blocks have been brought into one single block. This is much easier to understand by the simple fact that it's smaller.

Good Code / Refactored Function

If smaller is better then let's go a step further.

functions should not be 100 lines long
functions should hardly ever be 20 lines long
prior refactor was too long even in one screenful

public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception { if (isTestPage(pageData)) includedSetupAndTeardownPages(pageData, isSuite); return pageData.getHtml(); })

This function takes no time to understand. It is very polite.

Polite Code / Rules for writing a news paper article

If you read the news there is an expected format.

Start with a headline
Synopsis/abstract paragraph that describes the entire content
...more detailed...
...even more detailed ...
so on
so forth

The most detailed bit is at the very end. This allows you to read a bit and decide whether you are still interested, and that is polite. It allows for early exit as soon as you get bored of the detail. In code this allows you to read through what is going on without getting into unneccessary detail.

Having short functions with a single level of abstraction allows politely for you to dig as deep as you need to and to understand the purpose from each level.

Shrunk Code / The Rules of Functions

What's the proces of refactoring the long code into something shorter?

The rules of functions are as follows:

Functions should be small.
They should be smaller than that.

How many lines should a funciton be? It should fit on your screen. Originally a screen (once they were available in the 80's) would have been 24 lines by 72 columns. this follows from the fact that punch card had 80 holes per line and 8 were used for sequence numbers. This led to functions of 20 lines or less. But Uncle Bob's rule is that a function should do one thing.

In IntelliJ you can use the refactoring menu with an entry called extract method. If you cannot meaningfully extract another function then your function does exactly one thing. This means that you should extract methods as far as you can to have tiny little functions.

Before you say that this would lead to your drowning in thousands of little, tiny functions, you will not drown because you will have to give them names. As they are named they should be moved into appropriately named classes in appropriately names packages.

Shrunk Code / Drawing a Function

Long ago Uncle Bob wrote this function called gi. GI stood for graphic interpreter. It was 3000 lines long, but this was the general shape of it:

If some part of your brain relaxes when you see this shape then it's because you've come to know similar code it by it's landmarks. If rotated 90 degrees then it would resemble the horizon. This is something our brains became accustomed to over time. It certainly isn't because nested code is enjoyable to read or maintain.

If you have a couple of variables int i,j; that are manipulated in the first indent section. Extract method on this section. If i and j are both local variables then you can make them global for the time being. Now you can extract method on all of the funcionality that manipulates i and j, and you now have a bit of data and a set of functions that operate on that data. This is what we call a class. This refactoring method can help you to discover the true object oriented structure of the system that you are trying to design.

When and why was Java invented?

James Gosling in 1991 invented Java at Sun Microsystems in the Contract Programming division and there was a contract for a cable television set top box. Sun was dedicated to C++ at the time, but he hated the language so he made his own. He called it Oak, and he used it for the project and it worked and the contract ended which cast Oak to the garbage bin.

Sun Microsystems was a hardware company and their marketing scheme was selling hardware. They realized that if they wanted to be successful then they should win over programmers due to their feedback provided for buying systems. It would be really great if they could provide "the language of the internet" (whatever that might be). As they looked around found James Gosling had Oak. They took Oak and renamed it something more stimulating like coffee.

Prose Code

Indenting

Smallness also implies:
- functions should not be large enough to hold nested structures.
- 1-4lines would be ideal, 6 might happen occasionally
- therefore, the indent level of a function should not be greater than one or two
This, of course, makes the functions easier to read and understand

If you keep refactoring out chunk by chunk then you can make the body of if statements into function calls.

if(cupIsEmpty){ fillCup();}

This reads like well-written prose.

Arguments

Count

The best case for argument count to a function is zero as that is the easiest to understand. One is very straight forward as well. Two arguments can only be arranged two ways, but with three then there are 6 possibilities for ordering your arguments as it follows by N-Factorial. With 4 there are 24 options. Uncle Bob's personal rule is that a function shouldn't include more than 3 argments out of politeness to the reader. If you have a function and you want to pass six things into it, then if those six things are so cohesive that they should be passed in together why aren't they already collected into an object?

Booleans

If you are passing a boolean into a function then there is likely an if-else in that function. Pull that out and have a function of the if and a function for the else. doThis(4, 5, 6, true) is rude. What does that true mean? If it is really important then you would benefit from a method name that denoted what was being done if it is true. The exception to this rule is something like setFlag(true).

if(boolIsTrue) doFirstThing();else doSecondThing();

Isn't that easy to read?

Output Control

Arguments passed into a function for the purpose of collecting the output. It doesn't make sense when you are reading it. Your vertical momentum leads you to try to pass it over, but it demands that you come back and understand that out of place argument. It's a double take. It demands that you return to figure it out. If code causes you to do a double take that is rude. It forces you to stop what you are reading and go back.

Make sure that your code is not surprising.

Avoid Switch Statements

Switch statements are bad. If you have a switch statement that is on the type of a shape, then there must be an ENUM somewhere that defines those types. Switch statements will need to surround similar usages throughout your code. If you add a new type to the ENUM then you need to find all of the switch statements and make a change. Don't forget the if/else statements. When you need to add a new type, THEN you must go through and find all of the right places to add your new shape. This is overly complex.

Instead you should use polymorphism (inheritance) with a base class that contains the definition of the common functionality. Then each child class implements its own functionality and when you need to add a new shape then you only need to make changes in the new class for that shape, and it can be used by all of the other code that manipulates the different types of shapes. All of the draw, rotate, area, and other functions are wrapped inside the class and it manipulates its own data.

Open/Close Principle

A module should be open for extension,

but closed to modification

Switch statements cluster together dependency. There is a single module that has dependency on all of these outside modules. The switch statement is then used by some other modules. If there is a change in one of these dependencies of the switch statement then the switch code and everything dependent ON the switch code must be recompiled and redeployed. This breaks the ability to independently deploy parts of the system. Keeping interdependency minimal allows for independent deployment such as being able to deploy your GUI separate from your business logic. One really nice way to do this is to avoid switch statements.

Side Effects

A side effect is a change to the state of the system. The function open() has a side effect as it leaves an open file. Another such is new that allocates some memory. These side effect functions come in pairs, and we are really bad at remembering to call the second part of the pair. Garbage collection is a hack that allows us to forget about cleaning up the memory that we use. We still have to deal with opening and closing files and some other such pairs. Forgetting to let go of the resources that you allocate will eventually result in a system failure once the resources are depleted.

Using Lambdas To

A lambda is basically a class with one function called execute. We can use it to make open() safe.

void open(String fn, Lambda proc){ File f = File.open(fn); proc.(f); File.close(f); return;}

We now have a function that has no side effect. You pass a lambda into the function and the open and close are paired to prevent unintended side effects.

Command and Query Separation

A function that returns void must have a side effect, otherwise it is useless. A function that returns something shouldn't have any side effect. This is a convention called Command and Query Separation

Prefer Exceptions to returning error codes

Exceptions provide the opportunity to handle expliticly expected breakage states. Error codes are considerably easier to overlook.

If you are going to have a try block inside of a function then it is best to have ONLY the try/catch/finally and no pre or post blocks.

DRY Principle (Don't Repeat Yourself)

We want to avoid duplication as much as possible because it's sloppy. Move the duplicated code into a function, and if it is slightly different then you need to include an argument that allows you to know when to execute the different part. That works great for code that is duplicated.

Sometimes you find the manipulation of a complex data structure requires duplication of a looping structure. If you have lambdas then you can use them here, as you create a looping method that can be passed in a lambda for what to execute inside that looping structure.

Structured Programming

Edsger Dijkstra's Vision

Edsger Dijkstra was the first programmer in the Netherlands, and one of the first in the world. He survived Nazi occupation. He went into school and wanted to become a nuclear physicist. He saw the very first computer in the Netherlands, and went to his adviser and complained that there was no body of knowledge, formalism, or discipline in computers. He didn't think that his peers would take him seriously if he studied computers. The adviser suggested that he might be one of the ones that helps to define that formalism and body of knowledge. Dijkstra took this as a challenge and became the first programmer in the Netherlands. When he was married in the 1950's he had to list his profession. He tried to list that he was a programmer, but they denied him because that wasn't a known profession. He changed it to nuclear physicist. He said that he made the more difficult choice of programming over nuclear physics.

He wrote a letter in 1968 saying that goto was considered harmful which was extremely disruptive. This was rejected for years, and people wrote scathing letters in professional publications debating his argument. All these years later we don't have goto. His argument was that software should be like mathematics. There should be postulates and theorems that have been proven. These would be proven software that would be adapted by simple lemmas utilizing these proven pieces. He built up a mathematical structure of proof around if statements, loops, and many things. He discovered that certain algorithms cannot be proven correct because they have unrestricted goto's. This is basically Alan Turing's Halting Problem. Every algorithm can be composed of from three structures: Sequence, Selection, and Iteration.

Reality of Programming

We don't prove anything. Dijkstra's vision failed. We do lean on and risk our lives everyday on something else that cannot be proven. That thing is science. Science is made up of things that cannot be proven correct, but can be proven incorrect. We can surround something with enough tests that it's assumed correct. We can do similarly and demonstrate the non-failing qualities of software with tests. We may not be able to prove our software correct, but we can provide that it isn't incorrect by surrounding it with sufficient tests.

Who is Uncle Bob

Corey McCarty — Wed, 12 Aug 2020 00:00:00 +0000

After spending several hours listening to his talks, it occured to me that this information is needed by all developers and perhaps may be beyond the immediate consideration of beginners. In order to do my part to share the message of a man named Robert C Martin I will be writing a summaries of his talks as I watch them.

The Man

Robert C Martin is an American software engineer who writes wonderful books about writing code as well as teaching and talking on the material of his books. His website contains a great deal of information, and you have likely heard about these books as many are considered required reading for career developers.

Uncle Bob is credited with cretion of the SOLID principles, was a founder of the Agile Manifesto. He served as editor-in-chief of C++ Report magazine and served as the first charman of the Agile Alliance. His writing can be found at blog.cleancoder.com and you can find many of his talks on YouTube if you don't have the ability to attend one in person. He runs a consulting company as as a company that provides training videos.

In the coming weeks I will be writing beginner level summaries of his publicly available videos.

Happy Coding!

Use the Tools To Your Advantage

Corey McCarty — Wed, 05 Aug 2020 00:00:00 +0000

I see several content creators doing things in their posts that are easily done with the tools built into the DEV/Forem tooling. I've commented to several people about how they can make use of these tools to streamline their content publication without loss of functionality (and maybe even improve their brand quality/SEO in the process). Overall,

Links to Blogs

I 100% support people owning their content and publishing first on their own site. I do this as well. There are tools to utilize RSS and to link back to the original article on your site that are included in the DEV platform. In the settings menu there is a Publishing from RSS section wher you can add your Atom feed url. There are also option to Replace self-referenctial links with DEV-specific links which will bridge your dev articles on the same platform in a similar way to how you might link your blog posts together on your personal site. The other option on this page is Mark the RSS source as canonical URL by default which will provide a link to the blog post on your site in a special way that search engines will acknowledge your site as the origin of the material. This helps with SEO as search engines will remove listings of duplicate data and without a cononical reference it will prioritize the one with higher SEO/reputation and likely remove your original link.

Social links

I often see people providing a short bio and social links at the end of their post which is something that is common enough that the platform actually does this automatically using a card of your primary profile information. Firstly, you should make sure that you have filled out your profile information so that your profile doesn't give a '404 profile not found', but you can also add whatever links that you would like along with a short summary for display. The links will be listed on your profile card with their appropriate logo.

Links supported via Settings>Profile

Your Website
Facebook
YouTube
Stack Overflow
LinkedIn
Behance
Dribble
Medium
GitLab
Instagram
Mastadon
Twitch

There is also a Github integration where you can login to DEV using your Github account and pin certain repositories to your DEV profile page.

Lists of posts

There are a couple of versions of this that have different solutions. First is a list of all posts that you have. This can be easily omitted by asking people to check out your other posts from your profile (which has a link at the bottom of the article). The other type is for sets of articles to link to the other entries. The DEV platform has builtin functionality for this as well. Among the Front Matter information available in the editor guide is the series entry. This actually has some really awesome functionality. It will automatically generate a list of the all posts published in this series in order of publication. It will be updated once there is a new part published so that you don't have to go back and edit previous posts.

Summary

It pays to learn your tools in order to make better use of them. I highly recommend taking a look through the settings pages and the editor guide that is available via the i logo on comment and post editors. The DEV team has included a LOT of cool functionality that you can harness in order to spend less time on the tools and more time on the actual content. Honestly the only thing that I worry with in between posting on my site and posting on dev is finding a cover_image

Cover image by undraw.co

New Tools

Corey McCarty — Thu, 30 Jul 2020 00:00:00 +0000

Over the last couple of weeks I've had various people that I respect suggesting different tools to me and I've been really happy with the results. I'll share them with you below, but I'd also love to hear about whatever tools you have that might help others in their daily life.

ZSH

There are several option in shells for Linux command line and if you are anything like me then you may have just learned Bash as it was already there and gotten used to it. After years of seeing Zsh recommended, I decided to give it a try along with Oh-My-Zsh that is usually recommended for additional functionality. The command line experience is just given more power and polish with Zsh over Bash. This recommendation came to me along with the Command Line Power User course.

Features (as listed on Wikipedia):

Programmable command-line completion that can help the user type both options and arguments for most used commands, with out-of-the-box support for several hundred commands
Sharing of command history among all running shells
Extended file globbing allows file specification without needing to run an external program such as find
Improved variable/array handling
Editing of multi-line commands in a single buffer
Spelling correction and autofill of command names (and optionally arguments, assumed to be file names)
Various compatibility modes, e.g. Zsh can pretend to be a Bourne shell when run as /bin/sh
Themeable prompts, including the ability to put prompt information on the right side of the screen and have it auto-hide when typing a long command
Loadable modules, providing among other things: full TCP and Unix domain socket controls, an FTP client, and extended math functions.
The built-in where command. Works like the which command but shows all locations of the target command in the directories specified in $PATH rather than only the one that will be used.
Named directories. This allows the user to set up shortcuts such as ~mydir, which then behave the way ~ and ~user do.

Oh-My-Zsh

This is a framework for managing your Zsh configuration with helpers, plugins, and themes. It adds to the already wonderful Zsh experience and have found several included plugins that are very nice. My current configuration makes use of colored-man-pages, extract, alias-finder, common-aliases, zsh-interactive-cd, z, and fzf. I'm really enjoying them.

MobaXterm with WSL2

MobaXterm is a terminal emulator for windows. It can be used with different bash emulators. If you have the Windows Subsystem for Linux installed on Windows 10 then it will work together without any additional configuration. MobaXterm also worked flawlessly with my 'agnoster' theme for Zsh when the standard WSL2 Ubuntu terminal required additional fonts. If you aren't familiar with MobaXterm, it is a tabbed terminal emulator with split screen and MultiExec modes which can be a huge help when you are working remotely on different servers. I have used this to kickoff scripts on different servers at the same time or to jump through a gateway server into a build box to execute several scripts at the same time. I can ssh and enter passwords on several terminals at the same time to cut down on the setup time.

Notable

Notable is a note keeping tool for markdown files. This is a free product with a single developer maintaining it. It has a subreddit for support and the developer is very active there. I currently use this tool primarily for reading my notes as there are some things that I'd like to see added before I use it as my primary markdown editor. All of those changes have been acknowledged by the developer as being in planning. The biggest benefits that I see in Notable is the interface that allows you to add tags to your markdown files, collect them in notebooks, and quickly go between different groups. When a document is opened the default view is the 'preview' or 'rendered' html that results from the markdown, but there is an edit view that is easily entered in the same frame. Once the new editing features are added then this will be my primary markdown environment, until then I keep VSCode on deck with the Markdown-All-In-One plugin for composing markdown files quickly during meetings.

Cascadia Code Font

Really it's just having ligatures in general. I picked up Cascadia Code initially, but after adopting it for use in VSCode, I found that JetBrains Mono actually supports ligatures as well. It's a really small touch that I feel makes the development experience feel nicer.

Cover image by undraw.co

New Job New Tools

Corey McCarty — Fri, 17 Jul 2020 00:00:00 +0000

I recently started a new job, and it's only the second that I've had in my dev career. With a fresh look into how different it can be between companies, I thought that I'd share a few thoughts. I'd also love to hear yours in the comments.

Old Busted

I started off as a full time employee of a vendor company providing onsite/offshore model software development and support for a large logistics company. As such I never had much say in the tools that were being used. The company decided against allowing anyone to have admin rights on their local machine, and their 'official' take on IDE availability was that "Eclipse is the corporate standard and we will not consider making any alternatives available." Which was fun. This was even more fun when the vendors lost their desktop licenses for Microsoft Office when we moved to 365. It was also especially cumbersome to work from home when the vendors could not access the code repository or the test servers via VPN. Instead, you had to connect to vpn, then log in to a virtual server (after many failed attempts), and use whatever software was installed there to do your work. Overall, it seems like there was more concern with being secure than being productive.

New Hottness

I can't adequately communicate the glee that I experienced in my first week of work. I was given the option to have full license of IntelliJ IDEA or Eclipse. I got GitKraken, desktop applications for Office, local admin on my machine, the full Atlassian tool stack [Jira, BitBucket, Confluence, Bamboo] that auto-magically works together, and an account with Pluralsight matched with a standing calendar block to study every week.

While it has been a bit weird transitioning jobs during the pandemic, I have had the greatest experience with getting help with things. Everyone that I've asked for help is willing to stop and assist as needed. The work tasks are well defined, small units of effort with recommendations for solution. All that was necessary was to apply the change as recommended and then test. As I've needed access to an system I've been able to quickly request it and have it granted within 24 hours.

Conclusion

It's amazing how much different life can be in a new position/place. If you are in a tough spot, keep at it. Build your experience as you look for work, and eventually you will find a place that works well for you. Currently I can't imagine a reason that I'd leave my current role.

Cover image by undraw.co

What Makes a Good Developer?

Corey McCarty — Wed, 03 Jun 2020 00:00:00 +0000

I hear questions like this one at least once per week. To be fair, that may have something to do with the Code Connector community and it's culture. There are a great many people with non-traditional backgrounds in this group, and it has really helped me to better focus and realize the how little the schooling bit really influences ability as a developer.

I have come across a greatly diverse group of people that have a zeal for development. Many of those people are self taught. That zeal is really the only commonality that I see between all of the people that I would consider to be really good with coding. There is a drive and a passion with which they approach things. It makes sense to me. Having gone through college for computer engineering, during my schooling I would have told you the same thing about engineering students. You see, when your work includes fighting with stupid errors and working potentially long hours in order to correct errors that you didn't understand in the beginning, you will require a great deal of drive and motivation. That motivation will likely also allow you to dig around in documentation for things which you were never trained. The documentation will take some time to figure out by itself, but you will likely find something interesting in the documentation aside from the thing that will help with your issue at hand. Those little tidbits of information that you pickup over the course of time are the things that pile upon one another becoming the depth of your knowledge.

There is one level of programming work that can be done by anyone with a minimal skill set in development. These are the types of things that paid interns and fresh junior devs get assigned. Often times there are piles of this around any given project. You see anybody in this field can search the internet, documentation, and Stack Overflow for answers to these 'code monkey' tasks. These are the things that allow us to cut our teeth in this business and to become familiar. Our familiarity grows with the language, the framework, the IDE, the code base, and the process itself of development. Code monkey work is great for new devs (whether that be new to a project or to the profession), but doesn't ever actually stop during your career. These things can be pretty frustrating and not very exciting and in order to get through it you need to have a solid interest.

I see the same approach used in life and hobby of many developers. Common interests may include sports, video games, tablestop games, computer building, mechanical keyboards, traditional wet shaving or any of a million things with a depth of information that may be necessary to dig through in order to fully enjoy. This passion and excitablity is what allows these people to be good developers, games, and stewards of their chosen hobby.

The people that make great developers want to know how 'it' works; whatever it may be. They dig to figure out strategies for complex games. They spend hours on Massdrop looking for deals on really cool equipment that might not ever be available again. There IS a little bit of hipster in there for many. There is enjoyment in finding a thing that nobody else knows about. Even with programming that is a powerful position to be in. You might be the only one in the group that knows a given language or framework. This not only enables you to work on things where other may not be capable, but it also allows you to have the opportunity to help others with their issues. The sheer knowledge that a library or framework exists can be massively impactful to the direction of a project.

In what other profession can you have a long standing war such as 'vim or emacs' when both of them are a pain to use the first time? We have the ability to dig into difficult things and develop a love for them. There is a satisfaction in it.

The passion that we have enables us to sit and listen to someone talk about a project that we know nothing about and to follow along with the concepts being discussed. It isn't just a story of their current work, it is a knowledge entry for the use case of whatever tech stack they may be using.

tl;dr: anyone can be a great developer if they really want to be.

Cover image by undraw.co

Productive Mentoring

Corey McCarty — Wed, 27 May 2020 00:00:00 +0000

In order to advance as a developer you need more than just online resources. The most common question that I see in programming forums from juniors is about what they should learn. This touches on one of the primary needs for mentorship. There is so much information on the internet about software development that it is overwhelming without clear direction. Knowing what languages, frameworks, tools, and best practices are worthy of investing time is paramount. Even the people that have advised me about looking into job listings in my market to see what things to group together are what I would consider mentors in my career.

Personally I have had several mentors over my five years in the industry. Unfortunately the first four years were in the same team, and that's one thing that would offer me particular insights into the needs of mentorship relationships to evolve and eventually move on. The team that I spent the majority of my software career with had been together for a number of years before I joined. They were all excellent developers working with several technologies and managing a high volume CRUD system with a solid design and a homegrown build/deploy process. One of the first things that I learned in this team was that interacting with the Linux command line on the server was the most faultless way to interact with a system. This hands on approach permeated the entire deployment process. This Java web service was being deployed entirely by the team from the Java used by the applciation to the Tomcat servlet container that served it. Everything was managed and scripted by the hands of the team. At the time I didn't know any different approach so being so hands on with the bash scripting, building, deployment, database management (we had an AMAZING DBA that worked with us and trusted us to not break things).

It wasn't until I moved into a new team that I realized that, while I remained a junior within my old team, I had grown to a point that I could stand as a more senior developer with select skills that were not universal. My next mentor taught me a LOT about working in a much more complex environment. We tackled many things. While he heard and answered all of my questioning of the entire world, he helped me to understand that sometimes you have more work than you can get done, and the massive refactoring to make life better has tremendous value WHEN YOU HAVE TIME TO DO IT. There are times when urgent business needs require your focus over the cleaning of code.

It was only after working with the new team that I came to understand that I had outgrown my previous mentors. We had become peers as our skillsets grew to be very much the same. It is also important to note that none of my mentors had been 'assigned' as there was no direct program aligning juniors with seniors, instead it was my latching onto whatever more senior developers were around me in order to get whatever information that I could from them. I was being pretty intentional about acquiring the information, but many of them weren't intentional about providing information beyond the minimum needed for me to get a task done.

One of my best mentors probably count herself as such as we would become close peers as time drew on. What really made the mentorship so beneficial to me was that we would learn from one another and many times neither of us had the answers. At some point, one of us shared the Humble Bundle sale of No Starch Press books on Python. Even though we worked in a Java shop this was a great opportunity to learn something and the inclusion of Automate the Boring Stuff with Python made the bundle a steal. We would actually start using Python for some internal scripting as it was a bit more maintainable that a list of Bash one-liners to achieve similar results. We wound up going through a period of Humble Bundle acquisitions while talking together about different things. It was this learning and discussing that helped to motivate me to learn more. Due to some specifics of our software we had both become quite stagnant and aware that our skills were becoming increasingly difficult to market while looking for more work as we had both become bored of the work we were doing.

In order for a mentorship to work out well you need both people to be working to grow their skills. The skills of the mentor will eventually become known to the mentee if they are not growing.

The other major factor that will determine how well a mentoring relationship works is typically an assumption made of senior developers that they have good communication skills. The trope of 'good communication skills' is typically misunderstood. A wonderful quote that I've heard attributed to Albert Einstein is paraphrased as "If you cannot explain something to a five year old, then you don't truly understand it." This translates in tech as "If you cannot explain it to someone with substantially less technical knowledge then you don't know it well enough." That somebody with substantially less technical knowledge can be a junior developer, a business partner, or a client. Being able to communicate technical hurdles and determining factors in a way that enables knowledgable discussion is necessary for developers to advance. This actually comes back to my motivation for writing this as I heard someone say in Slack that they were being given the opportunity to be a mentor to some interns. My response (however poorly worded) was this:

Teaching is the best way to cement your learning. Please be aware that if you haven't mentored before that you probably suck at it. That isn't a judgement or saying that you shouldn't do it, but instead that you should be aware of how what you are doing may be working well or not. Be conscious of how well your mentees are understanding things. There is a certain amount of their not knowing things, but if it seems to be taking them longer than you think it should to grasp something then try to loop back and explain it in better ways. We can ALWAYS improve our communication skills, particularly when it comes to relaying technical information to people with less technical knowledge (whether that is a junior developer or a business owner). Good luck! You will get out of it as much as you put in, and if done well then you will have the opportunity to help form the way that these mentees approach development for the entirety of their career.

After having typed and sent that realized that it was a bit blunt, and the topic required significantly more information than I had initially provided. I hope that this elaboration has been helpful to you as you move forward in your career, hopefully carrying on relationships as both mentor and mentee.

Cover image by undraw.co

Carpe Diem

Corey McCarty — Thu, 07 May 2020 00:00:00 +0000

Cover image by undraw.co

Jobs come and go, and the long reaching career is each of our goals. How we handle each job will influence our own growth and professional reputation. It's easy to fall into doing the expected minumum. If you are anything like me, then you will find yourself looking back on our time with a team and question whether your impact was sufficient. I'm currently facing some changes in my job and I feeling reflective. Honestly I'm facing a fleeting situational depression and this is my therapy, so buckle up.

I've been in my current job for five and a half years and it's my first in this career. First project was six months, next four years, and most recent will be ending at exactly one year. I know that I've grown a great deal while working with each team, but in my reflection it dawned on me to consider how much growth I've been able to influence in my teams. If we are to be truly great at what we do then we should strive to become constantly better and to constantly help to make things better.

In my first role, I performed requirement illicitation for a fresh web service build. I was able to guide the questioning of the product owner and see to it that the development team (onsite and offshore) understood the requirements as work moved forward. I didn't get to see this one move into production, but I know that I wrote some utilities that enabled levels of abstraction that were honestly a bit absurd, but accomplished what was requested. I can confidently say that I made sure that this project stayed on course and made it quickly to production with minimal issues. Win!

In my second role, I did a LOT of support and configured our web service to accommodate new adopters as well as old ones needing additional functionality. I was able to assist with data modeling and best practices to help conform adopters to the patterns that best fit our application. I can remember being on 50+ count production support calls with customer facing impact and represtenting my team (while having the shortest tenure of the team) in resolving issues in a timely manner with VP's and directors all watching on. I can confidently say that I did meaningful work to keep the enterprise on track and minimize impact to the bottom line.

In my most recent role I seemed to find my voice as I had understanding on topics that other didn't and I was able to contribute more to the leadership and decision making. In a year's time I managed to make myself a subject matter expert for the new devops work that began not long after I joined, and subsequently never had to become extremely knowledgeable on the 16 actual applications that I was working with. I learned about cloud native springboot applications, Jenkins build pipelines, and groovy scripting of libraries for those pipelines and I was able to write pipeline scripts from scratch within that time. I know that I have created tools that will impact this team and their devops usage for possibly years to come. I continued to find things needing improvement and push for fixing any difficulty that wasn't a massive undertaking, and I feel good about it.

This reflection will surely stick with me as I move forward in my career and drive me to insure that when the time comes to move forward again that I can always see the positive impacts that I've had during my time there. I'd love to hear any thoughts and stories on the topic from your experience.