DEV Community: Nemo Oudeis

Make It Explicit

Nemo Oudeis — Tue, 30 Jun 2020 12:44:33 +0000

Recently I did some pair programming and code review with a developer, we added deep links into our Android application. All in all that's a pretty simple task.

During the cycles of code review and pairing I realized that I first recommended to use one technique during pair programming, just to argue against it in a later on in code review. That made me think - Do I have some type of split brain thing going on here? Why do I flip flop like that? 🤔

Let's look at code: The first version I saw (slightly modified) was this:

const val DEEPLINK_PATH = "/deepLinkPath"
const val DEEPLINK_SHEMA = "deeplink-schema"

fun handleDeeplink(intent: Intent?) {
    intent?.action?.let { action ->
        intent.data?.let { data ->
            if (action == Intent.ACTION_VIEW) {
                if (DEEPLINK_SCHEMA == data.scheme) {
                    if (DEEPLINK_PATH == data.path) {
                        data.path?.let { path ->
                            println("do the thing!")
                        }
                    }
                }
            }
        }
    }
}

Well this is overly complicated, if I would put it into plain language it would be:

I look at the intent¹, if it's not null, if it has an action, if it has data, and the action is ACTION_VIEW and the data has the URL schema that I expect and if it has the path that I expect, if the path is not null, then I do the thing.

Wait what? Huh?

Nobody wants to hear that. If I say that to you then your ears will start bleeding.

Not to speak of the indentation, it's horribly hard to read. This piece of code goes to great efforts to conceal its intent!

I suggested to simplify the conditionals and remove that indentation by introducing bouncer-style if checks. Moreover there's a design issue here that we conflate 2 concerns: (1) adapter code that translates between framework and our logic and (2) our own logic, which should be independent of Android specifics (like Fragments, Activitys and Intents).

My guy split the concerns and added the bouncer code, resulting in the below:

const val DEEPLINK_HOST = "our.deeplink.host.fyi"
const val DEEPLINK_SHEMA = "deeplink-schema"
const val DEEPLINK_PATH = "/deepLinkPath"

fun handleDeepLink(uri: Uri) {
    val schema: String? = uri.scheme ?: return
    if (schema != DEEP_LINK_SCHEMA) {
        return
    }

    // Safety check for host
    val host: String = uri.host ?: return
    if (host != DEEP_LINK_HOST) {
        return
    }

    // Safety check for path
    val path: String = uri.path ?: return

    if (path == DEEPLINK_PATH) {
        println("do the thing!")
    }
}

Now that's a lot easier to read, the indentation is essentially flat (ignoring the bouncer return statements) and we actually do a couple of more checks. Note also that the adapter code of checking if the Intent's nullability and if it has the correct action is not here (that's handled in the adapter layer as it should be).

But reading this I think: isn't that a bit verbose for the simple checks we do? Can't we reduce this to just a single conditional? Wouldn't that be more explicit?

So we arrive at:

fun handleDeepLink(uri: Uri) {
    if (uri.scheme == DEEP_LINK_SCHEMA &&
        uri.host == DEEP_LINK_HOST &&
        uri.path === DEEP_LINK_PATH
    ) {
        println("do the thing!")
    }
}

This is the final version, which is arguably more explicit and less complex than both previous iterations. In normal language:

If the URI has our deep link schema, host and path we do the thing.

Now that's a sentence! You hear it -- you get it. That's what the code should be like.

But I did tell my guy to

Add bouncer code because it will make the code cleaner
Remove bouncer code because it will make the code cleaner

🤦‍♀️

The poor guy must be thinking I enjoy making him jump through hoops to appease my sense of aesthetics. And I can see why he would get that idea...

Underlying this is more than a pattern, a technique, a specific design or a trick: I want the code to be explicit. All code should be explicit. This is such a universal guideline for me that I think it's a ... *drumroll*

Software Development Principle²

Style, taste and aesthetics are too subjective for my taste, so let's define a software development principle that I use to guide my decision making. Rather than detailed prescriptive solutions ("use bouncer code", "use strategy pattern") is a high level rules that I instill in my development teams.

Principle: a basic idea or rule that explains or controls how something happens or works

-- Cambridge Dictionary

Something fancy like that ☝️.

So get ready for...

Principle #1: Make it Explicit

Now this may sound basic at first glance, but bear with me.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-- Martin Fowler, 1999

Programming is communication with other programers. Therefore we have to strive to explicitly communicate the intent of our software.

Code should read like a story to the (to a reasonable extent) initiated reader.

Kent Beck recognizes that in his rules of simple design:

Passes the tests

Reveals intention

No duplication

Fewest elements

So if that's all over 20 years old, surely we all do this already, right? I wish....

Let me walk you though a couple cases I encountered "in the real world"™️, examples in which the code was less than explicit about its intent.

Example #1: Web Frameworks

Spring is a ~~decent~~ web framework, it has a lot of features and many people use it. Still I dislike Spring for the single reason that they make it damn hard to know what's going on! The significant code, the one that actually implements your business logic that -- you know, makes all the money -- is buried in a pile of annotations. This is only partially spring's fault, you don't have to do it way. But in reality I see code bases doing it that way. Here is an adapted example of some real java code that someone (with far more Spring experience than me) has written:

@RestController
@Api
@Validated
public class AnExampleController {

  @Autowired
  public AnExampleController(AnExampleService exampleService) {
    this.exampleService = exampleService;
  }

  @ApiOperation(value = "Get Example", response = ExampleResponse.class)
  @ApiResponses(
      value = {
          @ApiResponse(code = 200, message = "Success"),
          @ApiResponse(code = 400, message = "Bad Request"),
          @ApiResponse(code = 500, message = "Internal Server Error")
      })
  @GetMapping("example")
  public ResponseEntity getExample(
      @RequestHeader("subject") String subject,
      @RequestHeader(value = "alternativeSubject", required = false)
      String alternativeSubject
  ) {
    // Do the thing
    exampleService.doTheThing(subject, alternativeSubject)
  }
}

That's 12 annotations and 23 lines of code before you get to the point. That is not explicit, that's the opposite.

Similarly the data driven test code for class (this time in Kotlin) is a mess:

@SpringBootTest(classes = [ExampleApplication::class])
@WebAppConfiguration
@RunWith(Parameterized::class)
@Suppress("UNUSED_PARAMETER")
class ExampleParameterizedTest(
    /* parameters */
) {

    private var mockMvc: MockMvc? = null

    @Autowired
    private val wac: WebApplicationContext? = null

    @MockBean
    private lateinit var exampleService: ExampleService

    @get:Rule
    val springMethodRule = SpringMethodRule()

    @Before
    fun setup() {
        mockMvc = MockMvcBuilders.webAppContextSetup(wac!!).build()
    }

    @Test
    @Throws(Exception::class)
    @MethodSource("exampleParameters")
    fun someTestMethod() {
        // Do the test
    }

    companion object {

        @ClassRule
        @JvmField
        var SPRING_CLASS_RULE = SpringClassRule()

        @JvmStatic
        @Parameterized.Parameters
        fun exampleParameters() = listOf(/* test data */)
    }
}

All the effort you have to put in just to write a test... and slow running complex ones at that. I don't think we have to dive into the details here.

Ok so if Spring somehow makes people write hard to read code, what are some other options?

🤔

How about Node.js + Express? Let's look at another adapted real world example (again authored by somebody who is a more experienced express programmer than me):

// app.js
const express = require('express');
const app = express();

app.use('/example', require('./example-controller'))

module.exports = app;

// example-controller.js
const router = require('express').Router();
const service = require('./example-service');

router.get('/', async (req, res) => {
    const subject = req.header('subject')
    const alternativeSubject = req.header('alternativeSubject')
    // Do the thing
    service.doTheThing(subject, alternativeSubject)
});

module.exports = router

// tests/example-controller.test.js
const request = require('supertest');
jest.mock('../example-service')
const app = require('../app'); // the app file above

describe('The example controllor', () => {
    test.each([/* test data */], (/* parameters*/) => {
        request(app) // do the test
    })
})

Now this does most what the above Spring code does. In about half the amount of code. So express definitely facilitates more concise code. And I argue that just by that fact it already is more explicit that the Spring example. Nothing is buried in boilerplate here. Sure you may not know all the details of the Router or of the supertest package, but that is equally true for Spring's WebApplicationContext or the @Validated annotation. That's totally fine, explicit doesn't need to be verbose. We don't know all the things, that's why we read documentation.

What I'm getting at is that the express example explicitly communicates its intent. The spring example does not.

We could have done the same exercise with ktor, sinatra, flask, rails, etc. In this case the problem is not Java (although in many other cases it is) and even the spring project itself is trying to dig itself out of that hole with spring fu.

Rails advertises and delivers convention over configuration.
As a result the average rails codebase is more readable and communicates intent better than the average spring codebase.

Spring on the other hand often ends up in the "obfuscation over convention" corner.

Example #2: Generic Jenkins CD Pipeline

Here's Another real world example from a team that operates k8s clusters as a service for application teams. They have different environments (development, staging and production) and provide a Jenkins job to deploy to each of them, i.e. 3 jobs.
They decided to use a single Jenkins pipeline for all jobs and hardcode the credentials specific for each environment in the job config, for example the job deploying to staging environment has the env = 'stg' parameter hardwired in Jenkins web UI.

Here's the conditional logic of that pipeline, without the actual operations in each stage:

// Jenkinsfile
pipeline {
  parameters {
    choice(name: 'action', choices: ['deploy', 'delete'])
    choice(name: 'env', choices: ['dev', 'stg', 'prod'])
  }
  stages {
    stage('init') {}
    stage('build app') {
      when {
        expression { params.env == 'dev' && params.action == 'deploy' }
      }
    }
    stage('build docker image') {
      when {
        expression { params.env == 'dev' && params.action == 'deploy' }
      }
    }
    stage('select container image') {
      when {
        expression { params.env != 'dev' && params.action == 'deploy' }
      }
    }
    stage('promote container image to next env') {
      when {
        expression { params.env != 'dev' && params.action == 'deploy' }
      }
    }
    stage('deploy to k8s') {}
    stage('monitor rollout status') {
      when {
        expression { params.action == 'deploy' }
      }
    }
    stage('release notes') {
      when {
        expression { params.action == 'deploy' && params.env == 'prod' }
      }
    }
    stage('notify slack') {
      when {
        expression { params.action == 'deploy' && params.env == 'prod' }
      }
    }
  }
}

...now: tell me what stages run for action = deploy and env = dev? Can you tell? I can't, not without wasting effort untangling the mess. This pipeline obfuscates intent and control flow.

So my team split up the pipeline into 3, one for each environment:

// develop.jenkinsfile
pipeline {
  stages {
    stage('init') {}
    stage('build app') {}
    stage('build docker image') {}
    stage('deploy to k8s') {}
    stage('monitor rollout status') {}
  }
}

// staging.jenkinsfile
pipeline {
  stages {
    stage('init') {}
    stage('select container image') {}
    stage('promote container image to next env') {}
    stage('deploy to k8s') {}
    stage('monitor rollout status') {}
  }
}

// production.jenkinsfile
pipeline {
  stages {
    stage('init') {}
    stage('select container image') {}
    stage('promote container image to next env') {}
    stage('deploy to k8s') {}
    stage('monitor rollout status') {}
    stage('release notes') {}
    stage('notify slack') {}
  }
}

Now let me ask again: which stages run when we deploy to the development environment? Pretty obvious now, because there are no more conditionals in any of the pipelines! Isn't that much more explicit?

Ok, but that's maybe not perfect, there are some concerns you might raise

These pipelines are not equivalent to the previous above, the action = 'delete' cases are missing → We never used that - but we had no idea, because that was buried in the complexity of the previous pipeline. The code did not tell us, that was its little dirty secret.
There is of duplication in the pipeline we use for production & staging → Yes that is true. But we value explicit separation of these concerns is more over reusing code in this case. It is a trade off: simplicity vs no-duplication. Simplicity, I chose you!

See how something interesting happened there? Because we follow a this principle of "Make It Explicit!" we are empowered to violate the programmer common sense of "duplication is bad!".

Similarly following the principle lead us to identify a design problem: the pipeline clearly had multiple reasons to change, in other words: multiple responsibilities. By following our plan to make the code more explicit we also applied the single responsibility principle, without even thinking about it.

I have more examples of code that obfuscates intent, code that needs to be more explicit - but I think you get the point.

What is It Good for?

In summary: a lot of code is damn hard to read. Not because of programming languages or frameworks. Because programmers follow rules of thumb (reuse everything always, use annotations instead of code, etc.) without asking themselves: is this in line with my/our development principles? This is the first of the principles me and my teams follow, I'll write about the other ones in following posts - here's a shortlist:

Make it Explicit
Business Drives IT
Don't build Software
Trade-Offs & Decisions
Fast Feedback

This is a work in progress, non-exhaustive and specific to my professional environment -- but it's what I've got so for 😄. Let me know how principles affect your design & development and about your principles - maybe I'll steal some...

Originally posted here

Intent is an Android framework class, you can think of it as a value object that carries the intent of a message the operating system sent to your application. For example when the application launches or when the operating system sends a broadcast to your applications with updates of the battery level. ↩
I went back and forth between "principle" and "directive". Directive sounds less lofty and one definition is "something that serves to direct, guide, and usually impel toward an action or goal". Which is what I am talking about, kind of. But for the time being let's stick with principle. ↩

Master Your Tools

Nemo Oudeis — Tue, 09 Jun 2020 16:12:08 +0000

Originally posted here

Today I found "Most tech content is bullshit" by Aleksandra Sikora. Good title, right? 😁 In a nutshell her post says: all information on the internet is written by people who don't really know. And I'd say she's right about that. Still we point to them and say "this is the authoritative source, we should follow it!". I have seen & heard the same hand-wavy arguments, from junior, senior, tech leads, engineering managers, architects - really any job title and level of seniority. A lot of the time it plays out like this:

Expert: We need to do X!

Me: Why?

Expert: It's an industry best practice. Google is doing it!/I read it in a book. The author is famous!/I heard it at this conference. The speaker created a framework!/There is no other option!

Me: Why?

Expert: Because of the above!

Leaning into the external authority somehow has massive appeal.

Anyhow if you cannot formulate the problem, how your solution addresses the problem and the benefits and drawbacks of your solution then you don't know what you are talking about. At least you don't know it well enough. Unfortunately all the bullshit tech content (that Aleksandra is referring to) is the training material for the next generation of developers. It teaches them to ask: "How do I do it? And who said so?" instead of "How do I do it? Why? No I really want to understand it!".

Framework Induced Ignorance

I work several development teams on a variety of technologies. An anti-pattern I have seen on several occasions is framework worship: developers religiously follow the framework gospel (documentation & related blog posts) and ignore what developers have learned over decades - because React is new, how could your old idea apply to React?! I call this Framework Induced Ignorance, developers follow the $FRAMEWORK Way™️ and close their minds to other ideas. Let me give you 3 examples.

Android

The last 2 generations¹ of Android developers have followed the Android developer documentation. It taught them to....

... love god objects. Put all business logic into you Activity (or Fragment) - UI, business logic, external adapter code, what have you. Separation of Concerns - go home, we don't need you anymore!
... ignore unit testing. The testing skill in Android land is abysmal (compared to other communities). Most code is tightly coupled to the android platform, as a result the Robolectric project was born. It provides a work around to test your code, even if it's coupled to the platform - a hack to retrofit testing into a non-testable code base. (No offense to the robolectric folks, it's a great project.)
...forget about threading. On Android threading is inherently necessary, the UI thread has 16ms to draw the next frame. That's no time to do heavy lifting. Still the solutions promoted by the official Android documentation were error prone, clunky and have been rightfully deprecated (farewell Loader & AsyncTask, see you never). A lot of developers adopted reactive extensions just for the sake of explicit thread control. Talk about bringing a gun to a knife fight....

React

Recently I reviewed React.js code and one component was growing too big, it was several hundred lines of code at the time. The component is essentially an elaborate form, with different sections, which are semi independent. I've seen similar situations on other front end frameworks/platforms before, so I asked the developer:

Me: Can we split up the into smaller, self contained pieces?

Expert: No that is not possible in React, we cannot share state between functional components.

An hour of experimentation

Me: How about this → shows pull request. Can't we just call a function which returns JSX?

Expert: How does this work? I've never seen this before? Is there a blog post or documentation about it?

Me: I don't know, it's just JavaScript. A function that takes parameters and returns JSX, nothing to do with React internals really.

Later on he got really excited about this. Him sticking only to the React docs & related blogs closed his mind to "non React" approaches.

Spring

A third example is Java/Kotlin Spring. Spring is a great tool -- if you know how to use it. Sadly what I've seen looks more like Spring is using developers. A co-worker of mine, with a background the .NET, had to take over such a Spring application. He summarized it as "more annotations than actual code". Yikes.

I work with a Spring expert who followed exactly the same approach - he loves god objects, tightly coupled to each other and to the framework, all tied together with an overgrowth of annotations. Really very similar to the unfortunate Androids above. Now he's un-learning the anti-patterns that the spring community taught him over the years. But it's a slow process.

Wait a minute...

We've been here before. So much so that Uncle Bob already wrote about this in one of his books², so I'll just steal his summary:

Frameworks can be very powerful and very useful. Framework authors often believe very deeply in their frameworks. The examples they write for how to use their frameworks are told from the point of view of a true believer. Other authors who write about the framework also tend to be disciples of the true belief. They show you the way to use the framework. Often they assume an all-encompassing, all-pervading, let-the-framework-do-everything position.

If that sounds familiar it is essentially the same bullshit content that Aleskandra was talking about.

So now we're here, ankle-deep in bullshit content, how do we get out?

Craft beer, craft pizza, craft... software?

Developing software is a craft.

But what does that even mean?

In history the trajectory of a tradesperson typically included 3 distinct stages: apprentice, journeyman and master craftsperson³. Some of that system still remains in parts of the world, but only in traditional crafts - carpenters, electricians, butchers, etc.

What all of these trades have in common is:

You need knowledge of the trade
You need to apply that knowledge, over and over again to master different techniques and skills.
Reflect on and improve upon techniques & skills.

This applies to software development exactly the same way. You have to learn the basics about development and then do it a ton to become good at it. You can learn JavaScript and React basics in several weeks (step 1), but you need months to years to master JavaScript and React (step 2). What about step 3? That's how we separate wheat from chaff. If you aspire to be a software master craftsperson you have to go beyond the knowledge from framework documentation & blogs.

What's wrong with StackOverflow?

Well nothing really, it's a great tool, I use it a lot. But....

Copy-paste error message into Google
Finding a StackOverflow answer
Copy-paste solution
Repeat until your problem goes away

That will achieve the immediate goal. And if you do that over and over again you arguable follow step 1 and 2: Using Google and StackOverflow is part of the developer skillset, doing it more often will make you better or faster at finding these answers. But for step 3 you need to stop and understand why that answer solves your problem. What was the root cause of the problem? How does the solution address that? 🤔

If you want to escape the bullshit content you have to understand why the solution works. If you really understand the little bit of code you found that knowledge compounds. Soon enough it's time for you to write a blog post or documentation - and you sure as hell won't write bullshit content, right?! By practicing step 3, trying to understand every bit of code you write, at least a bit better that yesterday, you have a fighting chance. By mindlessly copy-pasting however...

Extreme Values & Reasonable Expectations

Why is that thirds step, the understanding of the solution, so important? Uncle Bob formulates a "list of perfectly reasonable expectations that managers, users, and customers have of [developers]"⁴ and among them is Fearless Competence:

Customers, users, and managers expect fearless competence. They expect that if you see something wrong or dirty, you will fix and clean it. They don’t expect you to allow problems to fester and grow; they expect you to stay on top of the code, keeping it as clean and clear as possible.

We aspire to be software master craftspeople in order to be fearlessly competent!

Similarly Courage is one of the values in Extreme Programming⁵:

Courage is effective action in the face of fear.

We aspire to be software master craftspeople in order to be able to act with courage!

Yet another way of putting it is in the Manifesto for Software Craftsmanship, with the subtitle

Raising the bar.

We aspire to be software master craftspeople in order to raise the bar!

⁶

Master your Tool

In summary

Aleskandra says "Most tech content is bullshit" - I agree
Generations of developers suffer from Framework Induced Ignorance
The only remedy practicing software development as a craft

Where does that leave us?

For all aspiring tech leaders/experts/architects:

Master you tools instead of being used and abused by it!
Create content along the way. Maybe yours won't be bullshit 😉.

I count a framework developer generation as 5 years. ↩
Clean Architecture, chapter 21 ↩
I prefer the term "craftsperson" to "craftsman" because there is really no reason to gender these terms. However using "journey person" instead of "journeyman" makes the writing less clear. ↩
Clean Agile, chapter 2 ↩
Extreme Programming Explained: Embrace Change, chapter 1.4 ↩
I know we started with discounting external authority, so let me qualify: I refer to these sources for different (better) formulations. And to clarify that these ideas are not my original thinking. ↩

Better Dev CV - one step at a time

Nemo Oudeis — Mon, 08 Jun 2020 10:39:58 +0000

Originally posted here

CV fresh out of `freeCodeCamp`

I saw this career advice question on freeCodeCamp:

I’ve been applying for jobs and I am getting really frustrated since I am rejected each time I apply. Perhaps there is something wrong with my resume

Last year I read hundreds of CVs and conducted close to a hundred technical interviews while hiring developers for my company. My key takeaway is: Hiring is tough - on both the candidate and the interviewer. So when I saw that question on the freeCodeCamp forum answers started pouring out of me. Here are some ideas for preparing a CV for a technical position.

Don't forget the README

If you have a project on GitHub make sure that (a) you have a README.md and (b) an uninitiated reader can understand what the project is about.

A good example of this is ReKotlin, they follow a simple structure of:

A 1 liner describing the project
"Introduction" section that describes the project at a high level
"About" section that goes into detail about design & details, with code examples.

Avoid Copy-Paste Statements and Templates

I see a lot of self described "motivated", "faster learning", "flexible", "innovative" applicants. If you don't provide evidence to back it up it will sound hollow - why should I believe you?. For example

I am a motivated self taught web developer and a fast learner who can transition easily into any new work environment

This mentions 3 skills: motivation, quick learning, adaptability. Those all sound nice - but if I don't see examples of past experience or behavior to support them they are claims to me. As a reviewer that is a bad sign.

If you don't have professional experience in software development you may have examples of motivation, quick learning or adaptability in other contexts.

Did you run a club in school/university?
Did you volunteer for something?
Have you been in a challenging work situation that you had to adapt to?

Giving a concise account (2-3 sentences) of this evidence shows that you are not just making things up and it is a great entry point for conversation during an interview.

Use Projects to convince me

You probably have projects or applications to show off your skill - that is great. I particularly like source code, I always review code to gain an understanding of the candidate's development style & practices.

However if you submit source code of a study/learning project I want to see it deployed as a functional demo (e.g. on Heroku). A running application, even if it is just a prototype, is much more convincing than just code. The technical reviewer of your CV will have confidence in your skill.

On the flip side if you submit a link to a huge and complex application I need more details. What did you work on? What challenges did you face/overcome? The main goal of reviewing past projects is to understand what you are capable of - if you make that really obvious you have an advantage.

Visual Presentation

The visual presentation of many tech CVs is a bit bland & loveless (some of this is due to recruiters, who copy content into word documents 🤦‍♀️).
This may seem a bit nit-picky but it has a big impact.

Typography: Don't use too many font sizes. Don't mix serif and sans serif fonts. Don't use text background (gray boxes etc.). Go easy on the bold & italics. I suggest you keep it simple: 1 font, 2 font sizes, use bold rarely.

Visual noise & white space: Many CVs are visually busy and dense. Typography helps. In addition to that using white space to visually group sections together makes your CV more readable. This is especially useful when the reader comes back to the CV to quickly find a piece of information that she vaguely remembers from the first read through (that happens 2-10 times for every CV that I read). Making the CV easy to use for the reviewer increases your chances significantly.

Hyperlinks: You are sending a digital document to apply for a position in tech. Nobody will type out the urls you put on the CV. They will click it. Therefore I suggest you put in clickable links behind descriptive titles.

🚫 Don't do

Sample project https://github.com/ReKotlin/ReKotlin

✅ Instead do

Sample project

OR

Sample project (GitHub, Live Demo)

Summary

I hope the above tips help you to make your CV clear and easy to read. If you have any more questions head over to the freeCodeCamp forum, I'll come find your question 😉.

DEV Community: Nemo Oudeis

Make It Explicit

Software Development Principle2

Principle #1: Make it Explicit

Example #1: Web Frameworks

Example #2: Generic Jenkins CD Pipeline

What is It Good for?

Master Your Tools

Framework Induced Ignorance

Android

React

Spring

Wait a minute...

Craft beer, craft pizza, craft... software?

What's wrong with StackOverflow?

Extreme Values & Reasonable Expectations

Master your Tool

Better Dev CV - one step at a time

CV fresh out of freeCodeCamp

Don't forget the README

Avoid Copy-Paste Statements and Templates

Use Projects to convince me

Visual Presentation

Summary

Software Development Principle²

CV fresh out of `freeCodeCamp`