DEV Community: codemattermedia

What inspires you to review Pull Requests?

codemattermedia — Wed, 06 Jan 2021 12:28:18 +0000

Not only is it part of most jobs, but pull requests by their nature allow for group analysis of contributions. Programmers love to write code, but for some reason, aren't as motivated to review them.

Trying to get someone to review your PR can feel like pulling teeth. It can take a lot of back and forth to finally getting your feature merged.

I tend to reserve my mornings for PR's. The idea is if done earlier in the day, the rest of the day could be for discussions, revisions, and anything else that comes up.

Do you make time specifically to review your teammates pull request?

Do programmers memorize code?

codemattermedia — Wed, 06 Jan 2021 00:33:11 +0000

Sometimes. Most engineers can't remember what they wrote yesterday but can write an algorithm by hand if asked.

Contributing to a shared codebase is like writing an endless novel with many writers, revisions, and a long history of changing based on the problem a particular piece aims to solve.

It's almost impossible to remember everything you or someone else wrote.

There is; however, some recall involved when programming. You've already memorized many words and phrases in the English language, and that's a great start since programming languages are in English.

Each language has its vocabulary and rules that need to be respected for things to work. You will want to memorize these. For example, JavaScript has some of the following keywords that you'll need to understand and remember to use the language to it's fullest capability:

variable declaration: let, var const
loops: for, while, in, etc

You will find these basic concepts in all programming languages, sometimes with the same syntax.

Memory works like a muscle. The more you practice something, the better you get at it. When engaging in deliberate practice of a skill, your nervous system sends electrical impulses to new areas of your brain. This action insulates the axons with a myelin sheath that strengthens the signal over time.

With enough repetition, your understanding of new concepts will be embedded in your long-term memory, making your recall faster than it was before.

How do I start to learn to program?

codemattermedia — Tue, 05 Jan 2021 13:38:19 +0000

Learning to program software begins with an interest in problem-solving. When it comes down to it, that's all that programming is; a set of instructions composed together to solve a problem.

Learning how to program is a lot like learning a new language. There are words and rules you need to follow to express and share ideas. Programming starts with understanding the meaning behind the words used to write software.

The good thing is that once you learn the common meanings behind the symbols and words used in programming, learning new languages becomes more comfortable with practice.

All programming languages share the same or similar concepts and structures. An "if" statement in one language means precisely that in another. Picking a language to write in will take some research as to what problems you'd like to solve.

Start by thinking about what interests you. From video games to stock market analysis, there's a world of opportunities for you to make something your own.

Endless videos and articles demonstrate what you'd be capable of writing. Do some homework on what interests you. Let your curiosity lead you towards what you want to create.

Once you decide what you want to make, research the technology behind it. Try recreating something you enjoy using. It doesn't need to be identical; a small subset of features should be sufficient to get you started.

Now start!

What is the best programming language for beginners?

codemattermedia — Tue, 05 Jan 2021 13:07:57 +0000

No programming language is better than another; they all can accomplish the same or similar things. That's not to say they're all created equal. However, they all share the same basic principles.

Deciding to learn to program is one giant step of many. Once you're ready to start, picking a language is often the most challenging - there are so many! 🤯

Most beginners tend to choose Python as their first language. It doesn't involve too much set up, and the syntax is clear and concise. Nevertheless, this isn't for everyone, and you should take a minute to evaluate your opportunities.

The first language you pick isn't as important as the resources available to support it. What good is a programming language if there's little or inadequate documentation? When looking for a programming language to learn, research the community for the quality of support they can provide.

You won't be surprised to learn that most programmers often search for their answers by reaching out to those who already solved their problems.

Sorting arrays, finding object differences, and anything else you can think of - someone else probably already figured it out. Even experts at the highest level need to refresh themselves if they're knee-deep in code and can't figure something out.

Community 🗣

Community resources are the benefit of starting with such popular programming languages as Go or Ruby. With that said, the first language you learn should lean towards what problems you want to solve.

If you want to work with the user interface, maybe JavaScript or Swift would be a sensible place to start.

Perhaps a little machine learning is something you want to take on? The R programming language is something to consider.

You may not know what type of projects you want to work with to start. That's ok! The first programming language you learn will likely not be your last.

Research 🕵🏽

Research existing products or projects that you enjoy, then reverse engineer them to find what language it's written in so you can start learning.

Once you get used to the syntax and learn the basics and programming principles, moving to different languages won't be as challenging as when you started.

The key here is to start. Don't let choosing the "right" language get in your way of propelling your career as a software engineer.

Working with Product Managers and Graphic Designers as an Engineer

codemattermedia — Mon, 28 Dec 2020 20:39:27 +0000

It's a genuine relationship in the ecosystem of software development. As much as people like to think that websites are about the coders behind them, it usually takes a bigger team of dedicated people to make it happen.

HTML, CSS, and JavaScript are just as crucial as Product Managers, Designers, and Software Engineers.

Your role as a software developer on a team is to bring your consumers' needs to life through code. Think of yourself as a conduit to technology and its capabilities and your users.

Working with a bigger team outside of engineers isn't typical for most programmers working at start-ups, as there are just not enough people to fill in these roles.

Larger companies with a hefty budget could hire a team of copy editors, designers, quality assurance specialists - the list goes on.

For those that find themselves in a new group of professionals that don't code, working with people in other disciplines can seem alien.

Before getting into how you can bring the most value to your team as an engineer, it's essential to understand the roles that key teammates play in the software development process.

Product Managers

Product Managers (PM's) are a special breed of people. They have a vision of the ultimate user experience from inception to completion. Interfacing with several levels of management, PM's are the cornerstone of your deliverables.

Just as software engineers think of all possible paths in their codebase, PM's define business goals and develop strategies, roadmaps, and milestones towards the final product.

As an engineer, PM's are the people you go to for understanding the why of what you're creating. Getting a deeper level of what a PM is trying to deliver will help you make the experience.

For example, after working with designers, a PM may come to you with concerns about load time efficiency due to the amount of traffic they expect to have at launch.

Your understanding of CSS can provide the comfort of letting them know that you can use native browser gradients and compressed transparent PNG's to minimize loading time.

Or it could be the case that instead of taking an approach that a PM had in mind, you can recommend a more efficient way of going about to achieve the same desired goal because of your deep understanding.

In either event, PM's are there to provide you with the guidance to achieve the best experience for the user.

Tips for working with Product Managers

Understand your audience

Who are you building this for? What screens will they be on? How do you handle unexpected errors? These are the types of questions you'll want to understand from your PM. Their answers bring you closer to the customer and fulfilling their needs.

Innovate and Communicate

When getting into the code, you may find inconsistencies in the experience that need intervention. Talk with your PM about this unforeseen route and how you could handle it. If it makes for a better user experience, speak up!

Get it in writing

Everyone has ideas, and most of them are great. However, without a plan, an idea is just that. Software requirements set up the expected outcome that the user will have. Specification documents come in many forms. The bottom line is to agree on something tangible that you can deliver.

Plan B

Your input shapes the experience. If what your PM wants isn't feasible or, frankly, impossible, have a backup plan. Show them what is possible using your field knowledge and experience.

Learn to Estimate

Everyone has a deadline. If there's a feature PM wants to build, but there's only a portion you can deliver on time, say that out loud. You can provide it in pieces overtime if applicable. Know your limits and capabilities and never take on more than you can handle. When in doubt, add padding to your original estimate; under-promise and over-deliver.

Designers

It's not only pretty pictures and pushing pixels. Designers
create visual experiences that guide the user toward happiness.

People like to look at nice things, and it's not easy to do. A designer's responsibility isn't to "just design," as there are layers of research and development that go into creating unique and visually appealing experiences.

From mock-ups to market research, graphic designers create engaging content for consumers to take out their wallets and spend money on products and services.

Would you buy a product off the shelf if the package design looked like an amateur's attempt to look professional?

It may be the best product in the world, but you'd never know because the inadequate packaging turned you away and onto another product.

We pay with our eyes just as much as we eat. Your relationship with designers is the bread and butter of this aspect of a creative profession.

Tips for working with Graphic Designers

Don't get attached to your code.

People know what they don't like when they see it. What you wrote yesterday could be deleted entirely - you need to be cool with that. Working together with your designer can help you reduce the amount of code you write.

Adapt to the Product.

Details are everything, and sometimes they change. Working directly with designers is a great way to build your creative muscle. Identify patterns in the experiences you're creating and code around them. Knowing the product vision before writing will help you keep your code modular and extendable.

Don't just build it; use it.

If an experience feels off, even if it's according to the spec (you got one, right?), speak up and let your PM know. When looking through a user's eyes as you're developing, you may notice ways to improve it. Your domain experience is part of the value that you bring, in addition to your coding skills.

Communicate in real-time.

Share as much and as often as possible. When you have a working demo, get feedback on your work. An open communication line with creators will ultimately help you create a better experience for the user.

Conclusion

A software developer's job is never over. From features to bug fixes, the body of code you contribute to may one day outgrow you. To leave your code in the best possible position for the next person to extend and maintain, learn to work closely with those whose ideas you help manifest.

10 Tips to Navigate a New Codebase

codemattermedia — Tue, 08 Dec 2020 15:06:37 +0000

Everyone is new to something at some point. When committing to an existing codebase with multiple contributors, you extend upon a foundation of ideas that came before you.

A bedrock of patterns, naming conventions, and ultimately decisions other people made about the software's direction at the time.

The keyword here is time.

Most software engineering teams participate in some form of agile-based methodology. A popular framework known as Scrum is a time-boxed cadence of focused energy on specific goals. They typically last two weeks or longer, based on the team's needs. What do people do with all this time?

Engineering decisions can sometimes lead to messy or unnecessary abstractions.

With little or no test coverage and slim documentation, hidden bugs are just waiting to be discovered by you, or worse - a paying customer.

No one person is to blame, as there are often many cooks in the proverbial kitchen. Maybe a product manager asked for a tweak on a feature shortly before a release, causing some funky code.

Or it's the case you slapped on some band-aid code that a future version of yourself would deal with eventually. Right. Whatever the case, I like to think that everyone tried the best at the time.

Perhaps at some point, you were or are the one building the roots of a project. Good for you! That's a lot of hard work. The decisions made here could have lasting impacts long after you stop contributing. No pressure!

When joining a new team, most engineers will find themselves adding to an existing codebase. Some of that code could be very outdated but still needs to be maintained for a business reason.

You could be dipping into some confusing code that someone threw together because they didn't have enough time.

Or maybe the requirements were sketchy and left out some edge cases that went unnoticed. It happens.

There are many stages throughout the life of a codebase. Whether you're starting from scratch, extending a bootstrap, or piling on a mountain of legacy Frankenstein code that you're worried about updating, how do you navigate the waters of shared code?

10: Find the Entry File

Your journey begins here! Thar be dragons. 🐲

Every program has an entry point. Most front end projects use an index.js file. Other programming languages use a similar file that represents the beginning of when the program runs.

Closely examining this will help you understand the flow of what you're reading. Here you may find functionality like:

Bootstrapping initial data
Setting up authentication
Making connections between shared systems
Landing or "home" page of a website

When loading up a project for the first time, it may not be obvious where to look to understand what's happening. Find the entry file and see where it leads you.

9 Help!

Mostly all codebases have some form of a helper file. Whether they are imported from a library or added by contributors, helper files do help.

Your mission is to see if there are any custom helper files. Custom reusable code added by contributors is an indication that whatever it's doing, it's essential enough to be shared.

Helper files usually have a variety of exported functions used by the rest of the application. Having them defined in generic files makes reusing in multiple places a breeze. Search the project for uses of any functions you find interesting. Please note how things are named, as they can provide clues to what they are responsible for handling.

8 Routes

The odds of the codebase you're contributing to having routes are high. No matter what the stack, routes are everywhere. From API's to URL's, route files give you insight into what is going where.

If you're working on a front end project, keep an eye out for how routing works by exploring the site. Click around, see where things take you.

Routes often have dynamic portions of the URL. An example could be /account/${uuid}. Follow that variable! Put the story together.

Taking a birds-eye view of the entire application will help you put it all in perspective.

7 Consistently Constant

At some point in the code's life, other files will need access to the same value. Much like helper files, constant variables get shared throughout the app.

You may find that the variables are IN_ALL_CAPS to indicate that they're constants. Variables written this way is an old-school naming convention used to communicate to the reader that its value won't be changing.

Examples of what you'd find in these types of files are:

API URL's
time formatting structures
secret keys or configurations

6 RTFM

Read (or write!) the F***ing Manual. Starting a new project involves some preparation. Planning docs can help you understand the business goals of the project. It's often these details that developers lack that lead to delays and confusion.

These come in design docs, feature specifications, workflows, user stories, user personas, storyboards, and many more. If you're lucky, you'll get access to some of these, as not every team has the people to produce quality documentation that others can follow. However, if you do, they will give you a greater understanding of what you're building.

Developer manuals are a different beast. This engineering-based documentation is to guide you through the code. Examples include Wiki pages, onboarding guides, Architecture Decision Records (ADR's), proposals, incident reports, readmes, and more. These docs are a goldmine for newcomers.

Having the goals of the business and the engineering specifics will help you become a better contributor. If you find yourself with little or no docs, then it's your turn to write them.

During your onboarding process, take note of anything that's missing. If you are following some docs that are outdated or incorrect, fix them! The next person will thank you.

5 Comments

Two forms of comments are crucial to understanding what you're building: discussion and code.

Examples of discussion comments are Request For Comments (RFC) docs, pull requests, and issue tracking software. These crucial nuggets of offline wisdom can help you understand how the code got to where it is. Check old pull requests to see how your team interacts when reviewing code.

Code comments are in the code. The kinds of statements are for humans - the maintainers of the code. They give readers a personal awareness of what's going on, describing business decisions or processes that aren't obvious by reading the code.

4 Follow the Herd

In an ideal world, the codebase you're working on reads predictably. It would look like every line was written by the same person.

Naming conventions are consistent, folder structures are intuitive, and everything is boring. Boring is good. It means that when you're kneedeep debugging something, it'd be simple to find and fix it.

When adding files, methods, functions, variables, or anything new, check for what's already there. Codebases are like one giant community-sourced story, a shared consciousness that lives in the code, and our minds.

Everything you read and write should look similar. Following established patterns makes extending and adding new features easy to follow.

If you're ready to break the chain and introduce a new direction or migration in the code, start with an RFC and get everyone involved.

3 Copy and Paste is your Friend

When contributing to existing codebases, you may find yourself adding functionality to something that similarly exists. If tasked to create a new page, look at other pages and emulate them. It could be the case that someone before you solved a problem that you can build on.

Examples of good copy-pastes can be error handling, page structure, and associated feature files that use similar functionality. Some frameworks offer command-line tools that generate starter files for you. Tools like this can increase predictability and productivity when contributing.

Adding a new feature could include creating similarly named files. For example:

account.js
account.test.js
account.helpers.js

Copy-pasting is only a start and should act as a template.

2 Tests

You may find yourself in a codebase without tests. If this is the case, you can be the one to write them.

Codebases with tests offer incredible insight into how a feature works. More importantly, they provide you a look inside your team's psyche.

Do they care about testing and quality assurance? Are the developers mature enough in their careers to see the value of testing?

Maybe tests aren't for every codebase. You may find yourself with the freedom of prototyping something quick, where tests may only slow you down. That's cool too.

However, if you find some tests, especially in production code that people depend on, run them yourself to see what's going on. If you've never written a test yourself, emulating what others have done is a great start.

1 Raise Your Hand

Don't be afraid to ask questions. Also, don't ask too many. You want to establish yourself as an independent thinker capable of figuring things out on your own. So, when do you reach out?

After you've exhausted every possible solution you could think of, maybe it's time. Before that, ask yourself some of the following questions as it relates to your work:

Is what I'm doing new for this codebase?
- Odds are, some functionality exists which you can build upon for your feature. Check for similar functionality that may lead you to your answer.
Do I fully understand what I'm writing?
- Too many times, software engineers code away without really understanding their deliverables. Get a clear picture of the result before working towards it. Googling all the things can only go so far without the right context.
Who can I ask for help?
- Everyone is busy. While onboarding, it's helpful to have a point person to reach out to for questions. If this person doesn't exist, take the initiative for the next person.

Spread the Love

Everyone is new to something at some point. Someday you'll be asked to buddy up with new engineers. They may be veterans to the field or starting their first job with your team.

Help them be great.

If you see a mistake in onboarding docs, fix it. If there are none, write them yourself.

Is logic in some code you found confusing to follow? Add some comments to help the next person.

The code you write today will be maintained by you or someone else way after you've moved on. Make it count.

What would you recommend to someone contributing to a new codebase?