Forem: Charles D. Villard

On certifications in the tech industry

Charles D. Villard — Wed, 23 Oct 2019 04:27:42 +0000

UPDATE:
While I think what the OpenJS Foundation is doing isn't a net negative and don't think certifications should be balked at completely, a friend and colleague of mine, Michael Schofield, made some excellent points regarding certification that I hadn't thought about.

// Detect dark theme var iframe = document.getElementById('tweet-1186871722177368064-329'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1186871722177368064&theme=dark" }

It's challenged me to re-examine my biases here a bit. If certifications continue to normalize in the industry, it can lead to employers having control of who gets in, thus gate-keeping. Certifications can also serve to put a developer in debt if they don't pan out, much like with degrees. Though I will say, to that end, someone intimate with the initiative did let me know that a diversity and inclusion program is on the wishlist to make it more accessible to those who typically can't afford it.

I encourage you to read through Michael's Twitter thread in addition to my sentiments below.

NearForm published a blog post recently written by one of their principal architects, David Clements. The piece announced the launch of two new certification programs: the OpenJS Node Services Developer (JSNSD) and OpenJS Node Application Developer (JSNAD) certifications.

The reception on Twitter that I saw was luke-warm at best. Much of the criticism was terse, primarily wondering why the OpenJS Foundation would back such an initiative. Why charge $300 for something people have been working on for years? Why introduce more gate-keeping to the industry?

// Detect dark theme var iframe = document.getElementById('tweet-1186731244165521410-588'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1186731244165521410&theme=dark" }

While I pride myself on being a self-taught developer, I have done certification coursework in the past for a couple of platforms. So, in light of the recent discussion including some I was involved in, I thought I'd at least put my thoughts on the matter out there.

Many software companies and third-party vendors offer vocational training and coursework for official and unofficial certifications. Popular opinion amongst developers is that certifications are often a sinkhole for money and time, and like I said, can be used as a gate-keeping mechanism.

// Detect dark theme var iframe = document.getElementById('tweet-1186837948483985408-628'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1186837948483985408&theme=dark" }

That's a point I can agree with. There are many certification programs that are often prohibitive to independent developers and only serve to create a false scarcity of talent for that specific work. I had such an experience earlier this year in a previous role, in which I had a soft requirement to pass a certification exam to be able to work with a large-scale CMS platform.

Despite that, I feel that certification courses can also be a benefit and boon to developers in some ways. Pulling from my own experience, I was able to participate in a vocational training course offered to me by the local government while living on food stamps in 2016. While I didn't take the certification exam and have yet to, completing the coursework was training enough to progress my career and helped me land my first full-time web development role.

While my situation is definitely unique, I find that many of the statements levied against the OpenJS certifications seem to be knee-jerk reactions to something commonly, though understandably, lambasted. Certifications and their coursework, in general, offer a structured environment or platform from which new developers or those familiar with other stacks can learn. They can also provide validation of a developer's skillset to potential clients, often in the Enterprise realm where software development is often discussed outside the engineering department at a high, unnuanced level.

OpenJS' certifications, in my opinion, improve upon that by creating an opportunity for that validation at a more reasonable cost compared to others. It also helps continue to solidify JavaScript's place as a useful programming language in the enterprise space, one dominated by Java and C#.

None of this is to say this is a perfect solution to anything or that there is even a problem to be solved with one more certification. Many developers build careers while never taking an exam, even though many often pay for courses, whether or not a form of verification is offered. I only hope to bring forward what I feel to be several benefits to such programs existing and to hopefully open a dialogue. What have been your thoughts regarding certification programs in the tech industry? Do you feel the community will benefit from a Node certification or could this be its bane?

Bringing DEV.TO to Your Blog

Charles D. Villard — Tue, 28 May 2019 17:58:59 +0000

If you follow software or web developers on Twitter, you're likely to have spotted some grumblings surrounding the blogging platform Medium. Many developers are considering making the move away from Medium ever since they took a walled-garden approach and started asking readers to pay a monthly fee for content written for free. Two popular options have been discussed frequently: either roll out a personal, custom blog or move content to another popular platform, dev.to (from which you're reading this article, by the way.)

Both are viable options, and given the prevalence of static site generators, are easy to accomplish. While building a blog grants you more control over its presentations, the benefits of regularly posting a blog on dev.to are nothing to sneeze at. The immediate upside is access to a large community of supportive and like-minded individuals, as well as built-in moderated commenting, SEO, and a conveniently located reader base at which to target your niche programming content. The dev.to team are also very transparent about what they're working on and what they can share, so you'll always see where things are going down the road.

Now, I will admit that I myself am a bit biased about dev.to. I've followed its progress from Ben Halpern's fledgling personal blog idea of The Practical Dev all the way to the robust platform and business it is today. If I could, I'd invest in it, is how much I adore this platform. All of that is to say, take my recommendation with a grain of salt. I feel like it's a great place to build your content and share it with the community, but I can see where having your own blog on your own site might also have benefits. Hopefully this post will show you a way that you can have both.

From the OG mailer packs.

A much requested but apparently little known feature of dev.to is its new Articles API, released earlier this May. It's a straight-forward REST API that allows authenticated users to create, update, and read posts. In updating my own personal blog, I've been experimenting with using it to bring posts in and display them on dedicated pages, and I feel that it has a lot to offer. I haven't delved into all the endpoints available to date, but I'll try and touch on what I have so far and discuss my plans for what I haven't.

What I present here is more of an experimental strategy than a prescriptive path towards using the DEV Articles API with static site generators. While the code will be from my own current implementations, I recommend looking at it as just a suggestion.

A quick note about assumptions and tech before moving forward.

As I mentioned before, a lot of the discussion I've seen has mentioned the option of rolling out a blog using a static site generator. Thus, the rest of this article assumes some familiarity with at least one static site generator tool. If you're unfamiliar with what a static site generator is, I highly recommended learning about the JAMStack architecture, and maybe exploring Gatsby or Gridsome, before coming back to this. Static site generators are a massive topic, but I've found these easy to get started with. I've already implemented this using Gridsome, a static site generator built using Vue.js, so my examples will be modeled on that. To the best of my knowledge, most static site generators will have the infrastructure in place to accomplish this, so don't feel locked into any one particular tool.

Displaying a List of DEV Posts

Let's start with getting a list of posts. The DEV Articles API offers a GET endpoint for retrieving posts that doesn't require any access tokens. All it takes is a query string appended to https://dev.to/api/articles.

https://dev.to/api/articles # Gets the top 30 "hottest" articles
https://dev.to/api/articles?tag=keyword# Gets articles tagged with "keyword"
https://dev.to/api/articles?username=thatUser # Gets articles written by thatUser
https://dev.to/api/articles?state=fresh # Gets "fresh" articles
https://dev.to/api/articles?state=rising # Gets "rising" articles
https://dev.to/api/articles?top=10 # Gets the top positively-reacted-to
                                   # articles from the past 10 days

Each request usually paginates the returned posts to 30 articles each. Getting the next thirty requires adding a page query string, so finding the 31st to 60th top articles from the past 10 days would look like:

https://dev.to/api/articles?top=10&page=2

Each of the JSON objects in the array you get back will contain metadata and front matter for each post that fit the query string parameters. So if we were to use https://dev.to/api/articles?username=cdvillard in the browser, we would get back an array of these suckers:

{
  type_of: "article",
  id: 90594,
  title: "RTFC: Why patience is a developer's best friend",
  description: "Patience as a virtue can mean a lot to a developer.",
  cover_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--Rqg-VarX--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/36d4a4hhje64epv8248d.jpg",
  published_at: "2019-03-12T22:24:53.528Z",
  tag_list: [
    "edit",
    "beginners",
    "productivity",
    "cdvillard"
  ],
  slug: "rtfc-why-patience-is-a-developers-best-friend-l95",
  path: "/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  canonical_url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  comments_count: 0,
  positive_reactions_count: 11,
  published_timestamp: "2019-03-12T22:24:53Z",
  user: {
    name: "Charles D. Villard",
    username: "cdvillard",
    twitter_username: "cdvillard",
    github_username: "cdvillard",
    website_url: "http://cdvillard.github.io",
    profile_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--cX9wiyae--/c_fill,f_auto,fl_progressive,h_640,q_auto,w_640/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg",
    profile_image_90: "https://res.cloudinary.com/practicaldev/image/fetch/s--xG2hWmsO--/c_fill,f_auto,fl_progressive,h_90,q_auto,w_90/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg"
  }
}

If you've published anything on DEV before, I encourage you to give it a shot and see what yours look like.

Following the recommended practices of your static site generator of choice, create a GET request for the articles you wish to query. This can be done using XMLHttpRequest, but I used the Axios library to make it a bit easier on myself.

  // Starts a GET request to the DEV API
  axios.get("https://dev.to/api/articles?username=cdvillard&tag=cdvillard")
      .then(response => { // When a response is received
        this.blogList = [...response.data]; // Add that to my Vue data
      })
      .catch(err => { // If something goes wrong
        console.log(err); // Log it to the console
      })
  }

You may have noticed that I'm querying not only my username in the request but also a tag of . . . my username? Why? Well, the DEV API returns anything it considers an article. This includes any posts tagged "discuss" which is DEV's way of indicating forum-like posts. Tagging articles I'd like to display with my username is simply a workaround to filter those out.

Bringing that data to the front end depends on the architecture of your particular static site generator, but once you've learned how to access it, you can iterate over it. Much of the power of a static site generator, after all is in being able to quickly build and implement a website, which usually means additional functionality for creating iterative markup using loops. In Gridsome, that means using Vue's v-for directive to call on the data and build on each object.

<!-- The v-for creates an instance of each "blog-preview" component 
for each "blog" in the "blogList" we got earlier, 
and attaches each property from the "blog" to an associated property 
of the "blog-preview" component. Kind of like connect-the-dots. 
If you want to learn more about Vue components and props, start with 
the Vue documentation at https://vuejs.org/v2/guide/components.html -->
<blog-preview v-for="blog of blogList"
  :key="blog.id"
  :blog-title="blog.title"
  :blog-description="blog.description"
  :blog-link="blog.canonical_url"
></blog-preview>

If all works out, you should see your articles being listed on your page of choice. If you want to see exactly how I accomplished this, feel free to take a look at my repo here.

My current work-in-progress placeholder with my posts

Displaying a DEV Post

So we've gotten a list of posts and links, but we haven't actually displayed a proper post. To do that, we need to make a call to a different API endpoint, specifically to the id of the article we're looking for. There isn't as much surface to work with on this part of the API, but you do get all of the information regarding your article, including the HTML generated by DEV's markdown renderer. Making a request to https://dev.to/api/articles/90594 will return a JSON object like this:

{
  type_of: "article",
  id: 90594,
  title: "RTFC: Why patience is a developer's best friend",
  description: "Patience as a virtue can mean a lot to a developer.",
  cover_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--Rqg-VarX--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/36d4a4hhje64epv8248d.jpg",
  readable_publish_date: "Mar 12",
  social_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--ENrc8Sz1--/c_imagga_scale,f_auto,fl_progressive,h_500,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/36d4a4hhje64epv8248d.jpg",
  tag_list: "edit, beginners, productivity, cdvillard",
  tags: [
    "edit",
    "beginners",
    "productivity",
    "cdvillard"
  ],
  slug: "rtfc-why-patience-is-a-developers-best-friend-l95",
  path: "/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  canonical_url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  comments_count: 0,
  positive_reactions_count: 11,
  created_at: "2019-03-12T22:22:46Z",
  edited_at: "2019-05-18T13:24:39Z",
  crossposted_at: null,
  published_at: "2019-03-12T22:24:53Z",
  last_comment_at: "2019-03-12T22:24:53Z",
  body_html: "<p>I'm typically not a patient person. It's a flaw I cop to a lot, and it's something I actively...",
  ltag_style: [ ],
  ltag_script: [ ],
  user: {
    name: "Charles D. Villard",
    username: "cdvillard",
    twitter_username: "cdvillard",
    github_username: "cdvillard",
    website_url: "http://cdvillard.github.io",
    profile_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--cX9wiyae--/c_fill,f_auto,fl_progressive,h_640,q_auto,w_640/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg",
    profile_image_90: "https://res.cloudinary.com/practicaldev/image/fetch/s--xG2hWmsO--/c_fill,f_auto,fl_progressive,h_90,q_auto,w_90/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg"
  }
}

The body_html property will likely be what catches your eye, as using that can cut out much of the cruft that comes with formatting a blog post.

Posting to, and Updating Posts on, DEV

When it comes to posting to DEV using the API, I have to admit that I'm still learning to use it myself. I have yet to experiment with it, but I feel that this is where the real power of DEV's API comes to bear. In theory, someone with a statically generated site will be able to cross-post to dev.to while maintaining their own site. How that's done exactly is a matter for another blog post, but given that we're working within the JAMStack, this is likely where serverless functions will come into play. I'll be experimenting with Netlify and a functions service in the coming days to see how to implement this.

Where to Go From Here

What I hope you'll take away from this is how flexible the DEV API can be, and how it is possible to both roll your own blog and post at DEV.to as well. As of this writing, I'm unable to comment on the effects doing so may have on SEO, but I don't foresee any significant negative impact that wouldn't drive traffic to finding you. Personally, I hope that those of you thinking about it will join the community and help make it all the more interesting. The more voices, the better.

RTFC: Why patience is a developer's best friend

Charles D. Villard — Tue, 12 Mar 2019 22:24:53 +0000

I'm typically not a patient person. It's a flaw I cop to a lot, and it's something I actively work on every day. I do my best not to be impatient with anyone or anything without a really good reason, but I'm terrible about being patient with myself as a developer. This character flaw of mine is one that's gotten my goat more than once, so I hope that, if you're about to embark on becoming a developer, that this helps you. And if you've been in the game a bit longer, I hope this endears you to your junior colleagues.

An impatient impasse.

The opus for this post came from a day working on a Vue.js component. It was my second production project using Vue, so I was excited to jump right in. After I got my developer environment set up, I looked for a smaller task to pick up just so I could get my feet wet with the other developers' code. What I settled on was a single file component for a modal. It would pull in data from a CMS to render a message depending on the URL. As someone who enjoys working with Vue and has worked with the library before, this seemed pretty simple to me.

I read through the user story, and started digging into the codebase. Once I got my bearings and put together a basic component, I wanted to be sure it would render to the page. I hit a mental block understanding how the components were being registered to the Vue app, so I asked one of my colleagues for a hand. This was a question that made sense to me because I had exhausted every possible idea I had, so I wasn't afraid to ask it. He pointed out that, while the core components were being compiled as a single file, many of the ancillary components like the modal I was working on were not, so they would need to be declared using a script tag in the markup.

So far, not so bad. I add the script tag and my component renders properly. Great, I think, now I can style it. It was then that I realized that there was already a modal component in the core library. Doubly great! I could simply re-use this as a child component and most of the work will be done. Pretty simple to me.

I began working on getting my component to play well with the modal. I skimmed through the code, trying to glean what made it tick, and tried something. I would then compile, refresh, and see that nothing worked. This went on for a while (read: hours). I could not figure out the issue. I would skim, try, and fail over and over. I would skim through the code, skim the docs, scrobble tutorials, but I still couldn't understand what I was doing. Eventually, I stepped away holding my head and thinking I don't know Vue nearly as well as I thought I did.

After a breather, I came back and looked at the modal's code one more time. This time, I read the code — not skimmed, read — to see what I was missing. Eventually, I came across it: an custom event to open the modal. Once I added that to my component, I breathed a sigh of relief.

A day in a developer's life

Let's get tangential for a second and take a look at what developers have to do on a daily basis. In a single day, a developer is likely to:

sit in on a scrum meeting to learn what everyone is working on,
read through a user story and gather information to discern tasks,
sift through documentation to find the best method to complete each of said tasks,
write and commit tests and/or solutions,
compile and most likely debug said tests and/or solutions,
ask around to see who can help with any issues,
submit pull requests to the main repo,
resolve issues from previous pull requests . . .

I'm going to stop there because I'm not trying to write an exhaustive or descriptive list, but that's more or less the working day of just a developer. I say "just a developer" because many developers wear more than one hat. Some developers may switch gears after lunch to handle developer relations, client relations, project management, scrum, or DevOps to name a few.

To the point of this post, then. With everything going on in a developer's day, it's extremely easy to become impatient, which can lead to a rough day of coding. As developers, we simply want to write Code That Just Works(tm). I've never seen this to be more true than for newer developers who have recently been hired. Suddenly, the pressure is on to show their developer chops, so when they can't find the answer on Stack Overflow or in the documents, asking questions becomes a game of "Shouldn't I Know That Already?" This begets a fear of asking, which begets a sense of panic when little code has been committed.

My biggest piece of advice to any newer developer is to actively practice patience. There's no rush to prove worth. There will be plenty of opportunity for that. For now, read the documentation. Ask all the scary, mean questions. Dig through the codebase. This is what will make you a better developer.

What exit should a .NET developer take?

Charles D. Villard — Fri, 16 Feb 2018 18:38:09 +0000

Is there a stack or language that .NET developers have found themselves moving to?

I'm currently working in a .NET stack, and it's also been a little bit of a slough as I work primarily on ASP.NET Web Forms-based projects and fewer MVC projects. I've been considering leveling up my skills to .NET Core, but I was wondering if anyone had any suggestions about other tools to explore.

Where to Move a Dev's Family while living with Seasonal Affective Disorder?

Charles D. Villard — Thu, 11 Jan 2018 00:20:41 +0000

TL;DR: Suggest a city with a warmer climate that would have a positive effect on someone with Seasonal Affective Disorder. If you have SAD, how do you combat its negative effects?

CONTEXT: Living in South Florida is can be really expensive, and when I began teaching myself web development in 2014 to provide for my wife and newborn daughter, I thought I'd be able to make enough with a dev job. Fast-forward to today, I've realized that that's still a ways away. I'm paid to code to full-time, but the costs have skyrocketed over the last four years.

My wife and I have hemmed and hawed about moving to another part of the country, but there's been one mental roadblock that we've hit every time: seasonal affective disorder. My wife was diagnosed with depression when she was younger, and weather can have a huge effect on her energy levels throughout the day. Living in Miami, she's been able to get things done thanks in part to a consistently sunny climate. On any rainy day, though, she can hit a slump really quick.

A mentor recently suggested the possibility of Austin, Texas. While an attractive notion, it's not something I simply want to dive into. Does anyone else here deal with SAD, and if so, where and how? Have you found a particular city or area that's helped combat the effects?

Designers, what resources would you recommend to a developer?

Charles D. Villard — Fri, 15 Dec 2017 03:57:04 +0000

When I started web development, I was hoping to work as a front-end developer. I was a bit passionate about it, and I still am, even though I work today in a full-stack environment that involves both JavaScript, Sass, and .NET. I've wanted to improve my skill as a front-end developer, and part of me feels like that involves a big more of a background in design than I have.

What resources would you designers out there recommend to developers who are interested in understanding more of what you do? A quick search of books brings up a few resources like David Kadavy's Design for Hackers and Tutplus' Design School for Developers but these seem a little dated. WOuld you still recommend these?

What's your trick to tracking your billable hours?

Charles D. Villard — Fri, 01 Sep 2017 15:16:02 +0000

While I'm asking this from the perspective of an employed developer, I'm sure this would apply to freelancers as well. I'm notoriously bad at tracking my time and want to change my ways so I don't play the TimeSheet Guessing Game at the end of the period. I know there are some tools like Toggl and basic note-taking, but it's one thing to know and another to do. Has anyone with the same troubles found something that works for them?

There Be Monsters in Working Remotely

Charles D. Villard — Tue, 18 Jul 2017 22:02:01 +0000

I'm lucky enough to have hit the one-year mark in June working as a web developer, and I couldn't be happier with it. It's come with some very nice fringe benefits; namely, the ability to work with a great team from the comfort of my home in Miami. I get pretty sweet weather, and the chance to work on my tan should I want to (still haven't).

This past year also gave me the chance to trip on many of the pitfalls that come with working remotely. You might be thinking I'm crazy for saying this, but working remotely, for all of its benefits, comes with its own set of baggage.

Don't get me wrong -- I subscribed to 37 Signals' manifesto well before I got my current gig. Working remotely was always the dream, before and after I ventured into web development. That being said, in my first remote job, I've come to learn that there be monsters in these depths.

Loose hours

You can't beat the flexibility of working remotely, right? You get to work from anywhere with an internet connection, and you can basically set your own hours. Well, typically, remote workers need to overlap at least half of their time with that of the main office, but you generally get to make it your own. Got kids in class? You can pick them up from school knowing you won't get wrung out for leaving your desk! Need to step outside for a bit? Cool! Out for lunch? That's fine - so long as someone knows you're away from the keyboard, you're good.

But when you start to feel like you could be using that flexibility for an extra-long lunch break? Watch out, because that extra 15 minutes can turn into an extra 45 minutes fast, and for any number of reasons. Remote work gives you some freedom, but you have to manage yourself. Keeping to a schedule seems easy enough, but it's not hard to get tripped up by something innocuous like traffic or other people.

Distraction

With all the additional freedom can come additional sources of distraction. Being able to work from wherever you like is the other half of that flexibility, but it opens doors to other distractions. Working out of a cafe can be awesome, but you never know when a busker might come in and start playing 'Sweet Home, Alabama' on a rusty guitar. Even at home, the distractions can be plentiful. Especially so when you have kids.

If you can work from home and not mind any additional distractions, then kudos to you. Otherwise, make sure you find a place where you can enter a sort of 'flow-state' with minimal distractions. Some situations don't allow for it as easily, but try and get the consoles, comics, fidget cubes, or whatever might distract you away for at least eight hours. If you live with other folks, be it family or roomies, make sure to have an agreement that you won't be bothered as much. Obviously not one set in stone, but at least let them know that if you're working, you're working.

Also, don't forget about the biggest distraction of all, the one staring you right in the face right now. Your computer and the Internet, with all of its wisdom, has to be the biggest distraction of all! There are tools to help with this sort of thing, but they are only that. It's up to you to use them.

Distinction

When you begin to work remotely, you might or might not notice a fine line between what's work and what's home. It can vary from person to person, but it's still an important realization to make. If you don't notice it, it can have an effect on your relationships with family and with work itself. One of the easiest pitfalls is to feel like you should keep pushing and giving it your all. It's a commendable sentiment, but it also defeats the purpose of working remotely: better work-life balance. Managing yourself also means managing when you're done, and when you can do that, you can make time for your personal goals and relationships.

This is probably the biggest 'gotcha' for me. Being at home with my wife and kid all day, I can end up working well past my personal work schedule before I realize what little time I have left in the day for them. Yeah, we get to have lunch together, but what's one hour compared to a whole afternoon or evening?

Now, I welcome you to take all of this with a grain of salt. Your situation and results working remotely will likely vary a bit from mine, but these are definitely things that can sneak up on you if you get too comfortable. I would recommend working remotely to anyone, but in the end, you have to be able to manage yourself well.

What's your annual self-review like?

Charles D. Villard — Fri, 30 Jun 2017 00:35:09 +0000

I've been lucky enough to hit my one-year work anniversary this month as a developer for Tenet Partners. It's been a great experience, and I'm learning more every day. Looking back though, I can't help but be my own worst critic. I kind of want to give myself a review on what I did wrong, and I plan on doing that, but it got me wondering. Do other developers do the same? What are some of things you guys take note of if you do? What are some steps you typically take to handle common issues, like timeliness on deliverables, and how do you implement them?

Hi. My name is Charles Villard, and I'm a web developer.

Charles D. Villard — Thu, 20 Apr 2017 07:20:38 +0000

Hi, my name is Charles Villard. I'm a web developer based in Miami, FL, and I work remotely with a great team at Tenet Partners. My workday tends to consist of C# in the .NET framework, JavaScript, jQuery, SCSS, SQL, and sometimes static sites in Jekyll and Wintersmith.

I've only been coding for three years, and it's been a whirlwind three years at that, at least for me. I started teaching myself HTML and CSS on Codecademy in 2014, and just kept teaching myself more and more about web development. These days, In my downtime, when I'm not being a family man, I'm trying to keep up with ES6, React, VR/AR in general; and I'm thinking of adding Ruby on Rails to that list as well.