Valuation, Visibility, and Retraction

In the bounds of our current world, some public voices is under consistent, overt scrutiny. I say some because not all public displays of voice are criticized as openly as others. The more attention an individual voice accumulates, the more susceptible he or she is to criticism. But not being so blatantly perceived as a public figure does not discount the value of an individual’s public statements.

While working in private investigations and digging through the body of content on the social media of my subjects, I was often astonished by their representation of themselves. That is to say, I think there was a disparity between these individual’s valuation of their voice and its actual meaning, relevance, and consequence. Individualized media, wherein an individual has a unique URL on a website, on which they are free to share their words, images, and other expressions, has potent meaning.

And I’m not just talking about the legal repercussions of publishing instances of written word or images. I am talking about valuation. I use this term because I think a lot of people do not completely understand that even under the guise of believed anonymity, their emissions matter. For example, when an individual takes part in the creation of the dramatization of a particular news event, he or she is in fact contributing to the narrative surrounding the event.

I have compiled some methods in which the individual can understand his or her contribution and value, whether or not he or she has a large following, or sense of visibility.

Valuation of Professional Persona

In my final week of coding bootcamp, it was suggested that we provide LinkedIn recommendations for the individuals that we worked with in groups during the course. This struck me as quite unnatural. As a new developer, I was asked to provide a gauge by which employers and other LinkedIn users would be able to then gauge another individual’s ability to perform at a job. Some may say that it’s “not a big deal” to provide recommendations.

And it’s not that I didn’t think that there were some individuals in class who would excel at a web development position. It is that I place value on my recommendations in such a way that I have to feel very confident about what I am saying, at least in that moment. I would be doing a disservice to my classmates by outlining such a microscopic part of their work, or by giving them a recommendation simply because I was prompted by the program.

When an opinion on someone else’s work is given out too freely, I am often struck by how exaggerated the praises are. Creating an overall higher valuation of my own opinions has quieted me. When I valued myself less and when I regarded myself as invisible to public scrutiny, I may have been quicker to provide recommendations and loud remarks about the earth shaking impact that an individual I barely know has made on the future of mankind.

In a transaction of recommendations like those on LinkedIn, we see an unsubstantiated view. Does the giving party value his or her recommendation, or is he or she simply giving the recommendation in hopes to receive one in return? Would the giving party speak the same way about that person around his or her friends? Or did the giving party feel pressured to speak a particular way about the person whom he or she is recommending. Now there’s also a question as to how the recommender wants to be perceived. Because remember, the recommendations also appear on the recommender’s LinkedIn profile.

Pride in Voice

While we should not have to live in fear of our unique voices, we should have a general consciousness of the weight of our voice. Even if we have not garnered attention in the public sphere and recognition of our mode of vocalization, we need to be aware that we contribute at least to a body of opinion, stance, and discourse. By putting more value on our voice, we can think more thoroughly about what conversations we are interjecting in. And we can evaluate whether it is even necessary or concerning that we engage with those conversations.

If you took a sample of the comments and other written material that you have published online, would you think this content was representative of your true self? Would you be displaying what you aspire to become, or are you presenting the part of you that is sad, alone, malevolent, and unfamiliar? I have read countless comments that I would categorize as unnecessary. There is a superficial way to place value on your written statements. That is, you place value on the emotional response you have in that moment of writing, your limited understanding of the situation, and your need to be part of a critical mass of commenters. Thoughts prompted by urgency and immediate heightened emotion are sometimes lacking depth, and pouring into an avalanche of voices is a sport of hysteria.

When we take pride in our voice, we do not need to be embarrassed if we do not feel the same way in the future. We can live in assurance that in that moment, we valued our written body of work. In The Unbearable Lightness of Being by Milan Kundera, one of the characters says:

“The pressure to make public retractions of past statements – there’s something medieval about it. What does it mean, anyways, to ‘retract’ what you’ve done? How can anyone state categorically that a thought he once had is no longer valid?” (179)

One of the theme of The Unbearable Lightness is the impermanence of life. Things occur once, and then they are done. If all moments are just that, valuation becomes all the more immanently important. In this moment, you have the opportunity to value your voice. In this moment, you have the opportunity to be in alignment with your values. In this moment,  you have the opportunity to use your voice in its full power. In this moment, you have to ability to value your words.

Our written trail is part of the culmination of our lives. Some of what we say has little social weight (depending on our social reach), but all of it is part of a progression. Valuation of your voice is an incredible power that you can give yourself. Nobody has to come and award your voice value. If you respect your voice and understand its value, you will have done yourself justice by coming closer into alignment with comprehending just how much you matter.

How I Operated During My Coding Bootcamp

A coding bootcamp is just a map. You have a general idea of the route you’re taking, but you’ve never been down that exact path. You also don’t know what the destination is. In the bootcamp, some of the work is going to be done for you – you’ll have technologies picked out, class times chosen, and feedback that’ll help you hone your skills. But at the end of the day, the coding bootcamp is not going to pull the weight for you. There’s a lot of work outside of the coding bootcamp to do, and a lot of self-motivation. I started prepping for my bootcamp before day one. You can read a bit about that part of my journey in this article. Here’s what I did to put myself ahead during the bootcamp.

Prioritize Often

The bootcamp I was part of met for ten hours of class per week. Throughout the week, it was my responsibility to allocate my time properly so I could be prepared for upcoming lessons, homework, and side goals (like diving deeper into MySQL). I kept a thorough record of what I had to accomplish in my paper planner. I’ve tried different methods of organization, and paper planners have always been what I stick to. I have purchased one each year for the past nine years and use mine religiously. I carry my planner everywhere with me.

Prioritizing has never been difficult for me, but I know that others have more difficulty with it. I have noticed that those with trouble prioritizing often are vocal about not having enough time. There are always ways to re-prioritize and simplify. I think that the reason I have not had much trouble with prioritizing is that I like to keep my life relatively uncomplicated. If an activity or relationship is draining and does not have enough value to compensate for the time and effort I put in, I will cut ties. There are other ways to prioritize, but the most important takeaway is that prioritizing is iterative. It requires consistent revision and attention.

Make it About You

No matter how great your support network is and how much external motivation you’re getting, the coding bootcamp is about your capability to return to yourself. I had to have a few reminders of this during bootcamp. At the onset of the coding bootcamp, I sat with some very negative students who often complained about how difficult the lessons were and about their lack of time outside of work to dedicate to their assignments and studying. I adopted the group mentality and complained a lot as well. Moving to another table and becoming more reserved in my interactions made me revisit why I chose to enter the bootcamp in the first place.

I also earnestly considered exiting the bootcamp about halfway through because I didn’t feel challenged enough. I didn’t trust that completing the program was going to open up opportunities for me. I didn’t see the destination; I was in the middle of an unfamiliar path that didn’t make much sense to me. How was it all going to tie together? What would I do once I got out of the program? After speaking to several people about this, I determined that I had already invested time and money into this track. I had to come back to myself and understand my initial motivations for entering the program, and disregard all of the negative reasons for not continuing.

Start Early and Code Often

The bootcamp I went to had weekly homework assignments that required us to use the topics we had learned in the previous week of instruction. I started all of the homework assignments as soon as I completed the previous homework. Doing this gave me plenty of time to think about the assignment, organize how I was going to writing the code, and provide a buffer in case things went wrong. I was methodical about my work, committing often and writing appropriate commit messages. With larger  projects, I gave myself three days of buffer for deployment because there’s inevitably something that’s going to go wrong, whether it’s with the service (in my case, Heroku), or with configurations on my end.

While I am not going to have the luxury of a three day buffer for deployment in the real world, I have learned a great deal about deployment. Anticipating issues and accounting for that in my timelines is a valuable tool in development. Organization is always going to be to my advantage. Another advantage that I offered myself was coding often. Since the beginning of the bootcamp in January, I made it a goal to commit code each day to GitHub. I do this to track my own diligence and keep myself on track. I know that dropping off would be counter-productive. I operate like this because I know that my personality loves consistency, and seeing the chart on GitHub makes me feel that even though I have not accomplished huge feats in this industry, I am still working everyday to know more and get better.

Tie Coding to the Other Things You Do

I like to see connections in the things that I dedicate my time to. So it was natural that I would incorporate coding into writing. Bringing the subject of coding into my blog has helped me solidify that these sides of me can coexist quite nicely. I enjoy being creative and didn’t want to have to give that up when going into web development. While coding is itself highly creative, I wanted to keep on writing and creating other types of media. I would say that web development has actually given me more of a creative edge, because I became inspired through coding to start interviewing people in the industry in my YouTube series, Coders Talk.

Everyone comes to web development with unique qualities and backgrounds. Those can only serve you if you leverage them in ways that accentuate your strengths. Tying coding into the other parts of my creative endeavors has helped me create more meaningful interactions and start to view creativity as a more public act. Before coding, I would not have had the confidence to create YouTube videos. Nor would I have had the confidence to ask people to talk to me one-on-one about their experiences. I’ve joined a huge community of people bent on self-improvement, who challenge themselves to learn and expand their abilities. I admire that about this industry, and it’s pushed me to do more.

Navigating a coding bootcamp is both a community and individual act. There are parts that you’ll have to go alone – namely keeping the momentum going, being consistent, and allowing yourself the time to learn. Oftentimes, community is also going to be involved. Your tools, lessons, and technologies are going to be handed to you, but you’ll have to learn to use them diligently and correctly. Operating in your best interest during bootcamp involves prioritizing, planning, and staying the course. Of course there are ways to get through bootcamp without taking full advantage of your time and strengths, but that will reflect in your abilities and body of work.

Development Notes for Caw

These are the development notes for the full-stack application Caw. This is a friendly user interface for the Watson Personality Insights AI. Basically, this AI takes in a portion of text containing more than 100 words and preferably over 1,200 words. With this, the AI provides some data about the author’s personality traits. Caw allows users to either plug in their text without logging in, or to create an account so that searches and results can be saved for future reference.

Github Repository

Note that this application was deployed on Heroku, a free hosting platform. If the page does not initially load, this is because the “dynos” are asleep. Please wait a few minutes, and you will be able to access the app.

Use the app here

Technologies and Methods Used

This project was built using React.js, JavaScript, Bootstrap 4, HTML and CSS, React Router for directing the proper components to their URLs, Express for the server, MySQL for the database, Sequelize to create the database models and ORM structure, and axios for front-end requests to the back-end.

I used two packages in this application that I have not used previously:

  • personality-sunburst-chart handles the graphical representation of the Watson Personality Insights data
  • sweet-alert is an easy way to add a beautifully styled alert. I used this to notify users that they have successfully created an account and prompt them to sign in

Note that I had installed and used email-regex, but decided to take this out after some issue with the React built. I originally thought that the issue stemmed from this package, but the issue had to do with uglify.js.

As for organizing the project, I used GitHub’s built-in Projects tab, which allows you to create a project tied to a specific repository. I created several columns including: To Do, In Progress, and Completed. I also created a daily diary of my progress, a copy of which appears below. On top of that, I kept written lists and notes in a notebook. I committed to GitHub often and used commit names that were logical, descriptive, and concise.

Challenges and Learning Summary

This project started out as a React Native application. However, given that the MVP was due within several days of me beginning, I chose to change course and build a React application instead. The reason being that I had a difficult time making progress on the original plan for the application, specifically the Twitter log in. Please refer to the proposal to see how much the application was divergent from the end result.

Building USUME prior to this application gave me a strong foundation for this project. There were many similar pieces: the passport configuration and usage, the overall structure of relation between the Express server and the React front-end, and the sign up and login logic.

The Watson Personality Insights AI was easy to work with and well documented. I knew that I wanted to visualize the data for the users, and looked into chart.js and canvas do accomplish this. However, I did not end up having to create my own visualization. I used a package that took the data from the API response and populated a sunburst chart. This package saved me a lot of time and trouble, and really emphasizes the community aspect of coding. Without the effort that those developers went through to create that package, I would have had a lot more work to do.

Day by Day Progress


  1. Finish setting up React-Native-App
  2. Create Twitter login component that includes the app title (currently a placeholder) and the Twitter login button (that’s not linked to Twitter)
  3. Set up the App component with RootStack and routing to login page
  4. Created new Twitter application to receive API keys through Twitter Developers
  5. Set up auth0 with Twitter on the auth0 website
  6. Confronting an error that is totally unknown. Terminal is only saying “Failed building JavaScript bundle”. Found some syntax errors with some help, however, the code is still not running.


  1. Could not get Auth0 working, so I deleted all the code that was used to configure it. I have to find another package for Twitter login that’s specific to React Native.
  2. Feeling very discouraged, and nervous that there are only a few days left before the MVP is due.
  3. Did some research and determined that create-react-native-app is not going to let me run link because Expo is handling the iOS and android files, which are the exact files that I need to reconfigure when I use the Twitter login package.
  4. I ejected create-react-native-app, which added the iOS and android folders. This way, I anticipate that I will be able to configure the proper files.
  5. Came up with the app name of Caw because it’s the sound that a Crow makes, and it’s louder than a Tweet.
  6. Spent a few hours dealing with Twitter login attempts at configuration. Basically, the packages out there require you to have an iOS folder, which I don’t have when I use Expo. Expo takes care of that for me. So I rebuilt the entire app not using create-react-native-app, but I was not able to build. The issue is not clear. I ended up reverting to the branch I last pushed to GitHub because nothing I was doing was working (which means I was able to build the files and view the app on Expo). Now I have to still figure out how I’m going to do the Twitter login.
  7. So after hours of frustration with figuring out the Twitter login on a mobile app, I decided that Twitter login is going to work better through React (not React Native). So I started a new project using create-react-app and an Express server.
  8. Created homepage and analysis components for the React application.
  9. Created React Router to direct traffic correctly.
  10. Added logo to homepage.
  11. Set up Express and cors to handle cross origin, set up the proxy as well.
  12. Set up Watson Personality Insights API that takes the content input from the analysis page and returns various criteria.


  1. Starting to style the analytics page
  2. Looked into Chart.js and Canvas
  3. Found an article about using chart.js with React but I may not have to use canvas


  1. Decided not to use Chart.js because there was a super easy npm package that I could use instead that would create the chart for me with all of the data mapped out. This package was made specifically to take data from the Watson Personal Insights API. It’s called personality-sunburst-chart
  2. Set up chart using the npm package to render with data from the API call


  1. Sign up logic completed, including checking for emails that have already signed up. This is done through checking with the database
  2. Create database, config for JAWS_DB down the line when I go live
  3. Create model for the Users table that has to store email, password, and id
  4. Add password encryption using crypt
  5. Add sign up form to the homepage, all styled
  6. Add front end validation for length of email and password
  7. Disable button until validation is met
  8. Re-code button linking to analysis page since the redirect stopped working


  1. Created dropdown log in form on the homepage
  2. Started implementing passport. I modeled this from my previous React project, USUME.
  3. Rebuilt the state and names for the signup form to account for the two forms on the homepage. They needed to be distinguishable.
  4. Created a loggedin page that will be accessible only when the user is verified.
  5. Installed the email-regex npm package and implemented this to check that the string inputted into the signup form takes the form of an email. This is the first time I have used this package and I remember that when I was building USUME, I was having trouble getting my regex expression to work with my front end validation. I ended up making a validation file for USUME that contained a regex email check function.
  6. Note that I still need to figure out how to decrease the size of the sunburst chart. At the moment, the chart is cutting off so not all of the text is readable. There is no good documentation provided by the developers of this package regarding this issue.
  7. Added text explaining the service on the homepage, and what happens when you sign up for the service, what happens when you log in, and what happens when you opt to use the service without signing up or logging in.


  1. Fixed the styling on the sunburst svg so that the whole image appears correctly and is not cut off.
  2. Set up second sequelize model for the logged in saved searches.
  3. Added loggedin, logout, and * to React Router
  4. Made notes about the remainder of the functionality to be implemented. Users will be able to access their search history through a listings page, and also be able to see detail pages for each result.


  1. Change the database association so that a user can have many saved searches and results. MySQL was a good choice for this project because the data is always going to be structured in the same way.
  2. Added logout functionality that ends the user session and redirects the user to the homepage.
  3. Added logout link to loggedin page
  4. Added links that direct the user to the homepage on the loggedin page and the analysis page
  5. Added check to see if user is logged in, which is handled by passport


  1. Made it so that the loggedin page is not accessible if you are not logged in.
  2. When you search and are logged in, your searches are pushed to the database. The detail listing page holds the results as well, so now I just have to be able to print them to the panels with the date and search text snippet.


  1. authUser route now works, which means that when you log in, the API grabs the past searches you have made
  2. Altered authUser route so that all data is passed to the front end
  3. Reordered loggedin.js to display results if they exist
  4. Printed date to results page. These date are currently stored in a datetime format, so they will need to be converted.


  1. Created cards to display the data from past searches. Styled the cards
  2. Displayed snippet of search query on the cards as well as the dates
  3. Fixed the panel date time so it would show human readable date using the npm package moment


  1. Prolonged logged in session by modifying the cookie session time (note that this would not matter later, as there were other issues cutting my session times short – namely when errors were arising)
  2. Broke my code by breaking out the log in modal into a separate component.
  3. Wrote a blog post about the million voices in web development.


  1. Fixed the login component so that now it works again. I basically reverted it back to what I had before, but now the signup and login components are separate.
  2. I started linking the saved search cards to a detail page.


  1. Created detail page as a new component.
  2. Created a new route that will get me information from the saved search cards to their detail pages


  1. Conditionally altered link on homepage to say My Account instead of Log In when the user is logged in. Do so on other pages.
  2. Added descending order to search cards on the loggedin page so that the most recent search would appear first.
  3. Made sunburst chart work on the detail page, and styled the chart so that it doesn’t bleed into the text box above.


  1. Added “email is already in use” error message to sign up form
  2. Installed sweet-alert npm package to create a message to the user when they have successfully signed up. This prompts a neat looking modal that thanks the user for signing up and encourages them to sign in to begin saving their searches.
  3. Cleared up some of the extra packages required in the routes
  4. Changed saved search card styling to eliminate text decoration underlining on hover
  5. Polished my presentation slides, which I started a few days ago.
  6. Set up Heroku application with JawsDB and the hidden variables.
  7. Encountered unsuccessful builds and was not able to resolve the issue today.
  8. Delete usage instances of email-regex npm package, originally thinking that the issue stemmed from this package.


  1. Deployed final build to Heroku. Note that the issue with the build was with minifying the files, so I had to opt not to minify. I confirmed that the app now work on Heroku and did some final functionality testing.
  2. Finalized notes

The Million Voices of the Coding Community

Web development is overwhelmingly community driven. We share tools, libraries, frameworks, code snippers, solutions, and questions. Our work would take tremendously more time and effort if we did not use each other’s code. Another way in which web development is community driven is also through the in-person and online help we seek. Throughout my past six months as a web developer, I’ve learned quite a bit about the process of asking and receiving help.

Getting the wrong kind of help

Not all people are suited to answering your question, no matter how much experience they have. Some will not pay full attention when you explain your problem. Others will disregard you as incapable of understanding. The hardest type of help that I have coping with is those who fixate on a part of your code that has nothing to do with getting to the solution. These are people who will begin criticizing your choice of software tools, minor and irrelevant details, and structuring (which can all be fixed at a later point). This distracts you from your core goal that the moment.

It’s important to be mindful of the people that you ask help from.

Not all people will be capable or interested in helping you. Nor will all people agree with the same coding standards and philosophies that you abide by. So it’s vital to find people who can focus with you on your pressing concerns and help guide you towards a solution.

I am generally cautious of people who hand out the code outright to my specific solution. You see people asking for others to do this for them on Stack Overflow. While this is a shortcut and may certainly help you achieve a result, it does not help you learn the intricacies of the code that you are putting together.

Getting the wrong kind of help can greatly discourage you, or even make you feel alienated from the coding community. But there will always be another person in this realm that you can reach out to and get support from.

Listening to all the voices at once

Listening to everyone’s input on your code is not going to make you a better coder. Why? Because everyone has a different method and opinion. Taking to heart all of the input you receive from your fellow coders convolutes what you are trying to do. It pays to listen, but be critical of who is speaking. Discard what isn’t helping you, and especially discard those things that are bringing you down.

There have been so many instances throughout my coding bootcamp experience that I have sought two, three, or four opinions on a particular problem, only to end up with a broken app and frustration. Refactoring your code at the drop of a hat because someone tells you it will be better their way may not always end well. Refactor your code because you see value in it, not solely because another coder tells you to.

Vet each voice that you listen to.

How much experience do they have with the type of problem that you are dealing with? Are you confident that asking for their help is going to get you closer to your goal? Have you exhausted the resources you could find on your own? This also applies to voices online. Though vetting a voice online is different than in person, it’s still important for you to determine whether you want to move forward with their advice.

Starry Night by Mark Basarab

Understand when you need to go it alone

Sometimes the best help that you can get is from yourself. Once you get on the train of asking for help it’s easy to reach out for even the simplest problems that you could have figured out yourself with some simple Google searching. Research is one of the top skills that a great web developer possesses.

Make sure that you exhaust your online searching before tapping your coding friend for help.

There’s comfort in knowing that you have reliable coding mentors, friends, and coworkers. But you will absolutely benefit from understanding the methodology of online research and self reliance. Reaching within for help can feel very rewarding and increase your confidence in your abilities.

There are a tremendous amount of voices in the web development community – loud, brash, uncensored, patient, open, intelligent. Not all of these voices are going to help you achieve your current goals. Some will make you feel like you don’t belong in this community. But if you want to be here, you belong here. Being a web developer is about a lot more than learning code. It’s about learning to interact with a whole new set of people with very passionate stances on their methods and tools. Not all of them will understand your goals, but some of them will.

Entering a community as vast as this one takes a fortitude that I have not had entering any other setting. It’s fast-paced, male-oriented, quizzical, confusing, and downright insane at times. This is an absurd community of logical thinking, perplexingly passionate individuals. Newcomers, welcome to the madness. For those who have been part of this community for some time, I hope you’re still in the honeymoon daze of contemplating the power of talking to machines. This community thrives on its voices. The loudest are not always helping the most, nor are all the quiet coders meek and soundless. There is room for the obnoxious and the tender, as in other fronts of life. Let us all choose our voices wisely, so that we may reach our goals.