DEV Community: Pablo Rivera

TinyMCE Django form won't submit.

Pablo Rivera — Fri, 28 Aug 2020 06:22:32 +0000

I'm building a django application that uses TinyMCE. Forms that had the TinyMCE widget were not submitting.

My models were:

    title = models.CharField(max_length=255)
    slug = models.SlugField(max_length=255)
    content = models.TextField()

The problem is that in order to use TinyMCE you have to change any TextFields to include blank=True.

Your code would end up like so:

    title = models.CharField(max_length=255)
    slug = models.SlugField(max_length=255)
    content = models.TextField(blank=True)

I was using a ModelForm which inherits certain properties from the model.

PS. Spent 2 hours with this. Hope I saved you as much time.

Relax, it's just code.

Pablo Rivera — Tue, 08 May 2018 04:08:42 +0000

A new codebase can be intimidating. In it lies the unknown. Bugs, spaghetti code, badly named variables, etc. During my trajectory as a developer, I've had to work on many codebases spanning multiple languages and technologies. Working on a new codebase used to make me a bit nervous. It's why I developed a system to turn those feelings into a net positive. In this post, I will share with you my system. Read on, it's pretty simple.

Stick to the basics

Every codebase is made up of data structures and algorithms. No matter the language. Everything revolves around those two things. By focusing on those two basic building blocks we can navigate our way around a codebase to gain insight and confidence.

Take notes of the data structures and break down the algorithms from the point of view of how those data structures flow through the program. Use comments, breakpoints, and print statements to document the flow of data.

One common gotcha of really awful codebases (commonly written in PHP and Java for some reason...) is that the data structures are defined as database tables. Keep this in mind when you are looking for the basics. Make sure to check stored procedures as well. 😉

Build on past success

Impostor syndrome tends to hit extra hard when we start working on a new codebase. It's absolutely normal to feel like that because new codebases bring new challenges we haven't faced before.

The way to attack this head on is to look back into our past success. Think about past work you've done on other codebases. Work that made the client (company) happy. Think back to how at the start of that same project you felt similar to how you feel now. You succeeded in spite of those feelings.

Start the race from the finish line

What does the end product look like? What do you have to deliver? This is not about specifications. This is about the actual finished product. What is it?

Define the end product in extreme detail. Fixing some weird crash on Android? Then define what the end product will be without the crashing.

Figure out your interfaces. What will your fix look like from the outside? Maybe the crash is related to a memory leak. Your interfaces must then revolve around avoiding memory leaks.

Hook your interfaces into the codebase. Make them pass through. Meaning that you are calling an interface that does nothing. Then dig into whatever data is flowing through.

Add your code to the interfaces. At this point, you are done looking for the problem and implementing a solution.

Take time off and rest

Tired developers cannot be effective developers. Taking some time off when working on a new codebase will allow you to ease into it rather than jump. It's better to enter the ocean through a nice warm beach than to jump from a cruise ship.

Happy coding!

The assembly line, code, and Big O.

Pablo Rivera — Wed, 14 Feb 2018 15:35:11 +0000

I'm currently refactoring a really messy codebase at work. It has made me think about the reasons about why it's messy. Last night, while watching an episode of Stranger Things, I realized why it was so awful.

Good code works like an assembly line

The reason this codebase is bad is simple: there is no clear step by step process of the state of the data flowing through it. There many things happening at once. The density of each line of code is very high. Global state is also used and abused. Understanding the status of the data at a given point in time is difficult. It requires detective work. Lots of it.

If we compare the old code to the refactor, the one thing that stands out is that the data clearly flows from one point to another. You can clearly understand how the input is transformed into the output. Just like how assembly lines work.

Wikipedia defines an assembly line as:

... a manufacturing process in which parts (usually interchangeable parts) are added as the semi-finished assembly moves from workstation to workstation where the parts are added in sequence until the final assembly is produced...

Using that definition we can make a connection that good code mimics an assembly line. It breaks down processes into steps (workstations) and things get added or removed in sequence until the output is produced. I don't know about you, but DRY, dependency injection, and a whole lot of other design patterns immediately came to mind.

An assembly line aims to for a constant O(1)

The other thing that annoys me about this codebase is the fact that every step is, at best, O(n). Accessing items on a hash table uses loops. Strings are built by exploding other strings. Just downright inefficient. There wasn't any thought of getting things done with the least amount of work. Good code is lazy. This one is as overworked as a fast food worker (I was one).

In contrast, the refactored code always aims for O(1). It doesn't always achieve it, but a lot of thought has been given to the data structures used. You see, the trick to performance is to always think about what data structure works best for this particular process. You also need to think in terms of the content of the data structures themselves. This messy code maintains every piece of data on global state. The refactored code keeps things local.

What does state have to do with performance? Let's use the assembly line example again. Imagine that you are building a car, and it's time to install the doors. Instead of the doors being next to you in your workstation, you have to walk all the way to the back of the factory to get them. That's not all. When you get there the doors are not sorted by color or side. You have to manually go through each door to find the one that fits. That's global state. Having one door for each side of the car in the correct color at the correct moment in the assembly process greatly improves efficiency. Your job is now simply to bolt the doors. Six bolts in total. One O(1) operation.

When I say that an assembly line aims for a constant O(1), what I mean is that each step is broken down to the point where the operations do not require a lot of processing. Each of the previous steps in the assembly line breaks down everything in smaller steps and state is always kept local.

Software engineering and manufacturing

I know there are a lot of people who are against the term software engineering. I understand why. There really isn't a by-the-books approach to it, yet. The industry is still too young for anything to be highly formalized. However, we can learn a lot from manufacturing. Studying how assembly lines work these days will provide a lot of insight. I suggest you look into it.

How to get hired through social media

Pablo Rivera — Mon, 30 Oct 2017 03:11:45 +0000

Note: This post assumes you already have a resume ready. Make sure to have one BEFORE you do anything.

My life changed when hurricane Maria destroyed Puerto Rico, and as a result, everything I had worked so hard to build. We decided to relocate to the US and I needed to get a job (I lost the two businesses I had).

I decided to leverage social media to help me find a good job. My first step was to identify people who could help me find a job.

How to find people who can help you find a job

There are a lot of good people on social media. More than you'd think. People who are not only able but willing to find you a job. All you have to do is find them, which is not hard.

First thing that you want to look for is their network size. A person with 30K followers/friends will have more reach than one with 500.

Second, and most important, is to look at their post history. Do they interact a lot with others? Do they reply to their own posts? You want to find people who routinely talk with their network. Avoid wasting your time on people who just post links (that account might be automated).

Third thing is to approach them in a friendly manner. Don't simply send a cold message. No. What you want to do is join in whatever conversation they are having in social media. But don't be a shill. Be yourself. This may take a bit of time (hours, days, weeks). It does allow the person to notice and appreciate your comments.

Fourth thing is to send them a message (public or not) asking if they know of any job leads. You can alternatively work that into whatever discussion they are having. Tech people are always talking about jobs, so it's not hard to do that (while not being a spammer and adding real value to the conversation). The person will either reply positively, negatively, or ignore you. If they reply positively then move on to the next step. If they react negatively apologize in a friendly manner. If they ignore you try again until they react.

OK, so now you have someone who is willing to help you find a job, what happens next? You need to share your info and resume.

How to write a post that will help you find a job

This sounds simple, but you will never believe how many people actually message me asking for help with this. The main issue they have is writing something that does not make it sound like they are clueless.

You can scroll down a bit a get a couple of ready-to-use templates if you don't want to read the explanation.

Write a clear headline or first sentence. This is what most people will read, so make sure that your purpose is stated quickly.

Example:

Good

I'm currently looking for a job.
I'm available for hire.
Python developer for hire.
I need a job writing python.

Bad

Software is my passion.
I can't pay my bills.
My car broke down and I don't have a job.

Add a short list of your top skills on the second sentence.

Example:

Good

I know Python, Django, Javascript.
Past experience with React, PHP, COBOL.

Bad

I built an app with React an it was really fun.
I mostly do Java.

Include a link to your resume or website.

If it's a website, make sure that people can find a link to the resume there. The less steps people need to take to view your resume the better.

Now, here is the whole thing. Note that it fits into a tweet.

Python developer for hire. Past experience with Django, Flask, and React.
Link to my resume: https://example.com

Ready to use templates

$language developer for hire.
Past experience with $technology, $technology, and $technology.
Link to my resume: $link_url

I'm available for hire. 
I know $technology, $technology, and $technology.
Link to resume: $link_url

I'm currently looking for a job.
Know $technology, $technology, and $technology.
Link to resume: $link_url

What to do once your info is shared

At this point, people are sharing your post with their networks. This is where the real work begins. You do not sit back and wait for people to contact you. No. Your focus now is to identify people who are in a position to hire you. How do you do that? Simple. They will reply to your post and ask to get in contact with them. Always reply on the post thread and let them know you sent them a message.

Some people assume that jobs will magically arrive to their inbox. Nope. You have to contact and follow up on the people who replied to your post. Make a list with their contact information and make sure to message them privately. Be friendly and don't expect them to hire you. They are simply potential leads. You are free to ask about the job but always let them reply first. The first message must be short. Wait until they reply to ask questions.

Yes, this is a fair amount of work. Nobody said it would be easy. The upside is that the jobs tend to be better than using a job board. Why? Because you can get job leads for jobs that are not even available yet. You can also connect with great recruiters this way. People will also share very helpful links to local groups that may also have job boards. Groups you would not normally hear about.

Until next time!

ðŸ™‚

How to do technical blogging

Pablo Rivera — Thu, 24 Aug 2017 06:20:14 +0000

Quick Summary

In this post, I will show you how to write technical posts. The post outlines the structure of a technical post in detail, provides some useful examples, and some important tips I've learned from experience.

Intro

One of the reasons software developers start blogging is to share their technical knowledge and experiences. What some don't realize is that sharing that technical knowledge is a skill they have to develop on top of basic blogging skills. On this post, I will show you how to write technical posts.

Structure of a technical post

Technical posts are structured differently than regular blog posts. A technical post requires you to provide meta information to the reader because they might decide to implement whatever it is you are explaining. In general, the structure of a technical post is the following:

Headline
Quick Summary
Requirements
Introduction
Multiple step explanation
Examples
Tips
Summary

Let me explain what each of these are.

Headline

The headline in a technical post is very important. It is the part of the content that tells the reader how to do something. That is why a lot of technical headlines use the "how to do X" approach. It is clear, straightforward, and void of any confusing terminology (last thing you want to do is confuse your readers). If you haven't noticed, the title of this post is an implementation of this approach.

Other headline types that are very useful are the following:

Writing a $technology $thing.

Developing with $technology.

Testing $technology with $thing.

Notice that there is a very simple pattern at work. Useful technical headlines tend to start with verbs that provide a quick explanation of what the article is about without the reader having to spend any time reading it.

Quick Summary

The quick summary is not always necessary but it is definitely useful most of the time. It saves reader's time by summarizing in 2-3 sentences what the post is about. Think of the quick summary as a longer kind of sub-headline. It is important to have a relationship between the headline and the quick summary. Where the headline stops, the quick summary should continue. Read the headline and the quick summary of this post and see how smooth the transition is.

Requirements

Requirements are things readers need to have in order to successfully read and apply what the post covers. If you are writing a Python tutorial, then the requirements would be: Python version used, a text editor, etc. Be very specific and include versions when possible. Let me use the example above to show you how it's done:

Requirements:

Python 3.6.1

Text Editor (Vim was used for the examples)

Operating System (Linux, MacOS, Windows) with version information (Ubuntu 16, MacOS 10.12, Windows 10 Professional)

Requirements are important because software varies from version to version and from platform to platform. Clearly specifying what you used lets the reader know if they are equipped to follow along. If not, they can prepare before continuing. This is an area a lot of technical posts fail and leaves the reader to figure out any issues on their own. A good technical writer saves the reader from this frustration.

Introduction

The introduction explains what it is that you will cover on your technical post. It is the place to get anything non-technical out of the way. People often begin including technical details in introductions. This is not a good idea because introductions can be long and not well structured. I hate it when people include obscure technical details in introductions because it immediately throws me off. Here is a good sample introduction:

Python has become the defacto glue language in software development. In it's newest version (3.6.1), the language has evolved into a powerful tool that is easy to pick up. Python is included as a default in most Linux distros, and in MacOS. Such widespread adoption means you will probably not need to install anything in order to run Python on your machine. Follow along as I explain how to use Python's F-Strings in a Linux environment.

Notice how the introduction sets you up for success by providing some light background information without including any technical details that would be necessary later on and have not been previously outlined in the requirements.

Multiple step explanation

This is the area where you explain things in detail. I emphasize multiple steps because breaking things down into smaller parts makes things more manageable for you as a writer and allows readers to quickly pick up where they stop. Multiple steps are also necessary to paint good mental pictures in the minds of readers.

How granular should each step in the explanation be? As granular as possible. Sometimes they may be one sentence long. However, length is less important than scope. Let's talk about scope a little bit.

Scope in technical posts is the same as in programming languages. You have local and global scope. Global scope means that the information being discussed in some place applies to everything else. Local scope means that the information being discussed applies to whatever you are reading right now.

Each step in an explanation has local and global scope. Meaning that the information discussed in each step is important to the step itself first, and second to the general post. But not the other way around. Scope has precedence and it's very important. Having the wrong level of scope in any part of an explanation will confuse the reader.

There are multiple ways to encapsulate scope locally with the help of visual cues. Visual cues are graphic or typographic elements that allow you to let the reader know that everything within specific area is closely related to itself (local scope), but not very related to the global scope. Let me show you an example:

#######
#
# This is a globally encapsulated scope. 
# Note that everything that I write here is assumed to be directly related.
# 
# I wrote this post as a result of a Tweet!
#
######


######
#
# This is a locally encapsulated scope. What I write here is separate from the rest.
#
#  #####
#  #
#  # How are you enjoying this post?
#  #
#  #
#  # #####
#  # #
#  # # Yes, this totally looks like OOP. It is not a coincidence. :)
#  # #
#  # #####
#  # 
#  #####
#
######

One thing I want you to notice is that the deepest level of scope is still related to the other two, but has precedence when it comes to communicating ideas. People tend to read the deepest scope first. This is a very important point. The order people follow when it comes to scope is deepest first. Using the example above, the will tend to read the text above in the following order:

First -> Yes, this totally looks like OOP. It is not a coincidence. :)
Second -> How are you enjoying this post?
Third -> This is a locally encapsulated scope. What I write here is separate from the rest.

In summary, break things down into smaller steps and provide visual cues that inform the reader of scope. Keep things that are locally related to a specific step. When in doubt, break things down and provide visual cues. It is better to have multiple small (micro) steps than a handful of big ones.

Examples

Providing examples is a necessity these days. People will usually skip everything else and go to the examples. That is why it's important to repeat everything in the examples. Yes, that means including the requirements and the multiple step explanations as part of the examples. You will not copy and paste the text into the examples, but you will provide a more concise version of them.

Examples are the most important part of a technical post because people will leverage them to understand whatever it is you are discussing. In fact, how people react to a technical post is directly related to how good the example provided are. The more examples you can provide the better. However, make sure to provide examples in different lengths and types. You don't want to forget including a "Hello, World" example, but you also don't want it to be the only example you include. Using Python's F-Strings, let me show you some examples that you can learn from.

Very simple example used as an introduction:

# python 3.6.1 on MacOS 10.12

# Hello world with F-Strings

name = "World"
print(f"Hello, {name}")

Simple example showcasing some specific technical detail (local scope):

# python 3.6.1 on MacOS 10.12

# Using Python's F-Strings in functions

def hello(name):
    return f"Hello, {name}"

def print_hello(name):
    print(hello(name))

A more complex example would be:

# python 3.6.1 on MacOS 10.12

# Implementing FizzBuzz with Python's F-Strings
# and ternary operators

def fizzbuzz():
  for i in range(1, 101):
      print(f"FizzBuzz with number {i}") if i % 3 == 0 and i % 5 == 0 else None
      print(f"Fizz with number {i}") if i % 3 == 0 else None
      print(f"Buzz with number {i}") if i % 5 == 0 else None
      print(f"Now on number {i}")

The point is to ramp up the complexity of the examples to guide the user on their learning journey. Each of the examples above build on the last one and share one main subject: Python's F-Strings.

Tips

I decided to include some tips I've learned throughout the years. Some of these don't always apply, but are useful to know.

When in doubt, explain. Explaining more is always useful. You can avoid writing walls of text if you use visual cues to provide more in depth explanations. By separating them with visual cues, people can avoid reading them if they quickly understand
Avoid using low contrast colors for visual cues. Light grey font on a dark grey background is not very good. Make it easy to read.
Have multiple people read it. Feedback is important. It's the difference between something that most people understand to something that confuses everybody. It is very easy to write confusing technical posts due to their nature.
KISS. Keep it simple, stupid. Don't include an avalanche of details when a handful will do.
Study highly praised technical posts or documentation. People love to praise Stripe's documentation. Figure out why and apply what you learned to your post.
Use graphics to break down the text. I normally stick to using as little graphics as possible, but they can be useful. It depends on what is being discussed. Most of the time you will have to draw your own graphics. Don't make them too colorful. Stick to 2-5 colors and keep them simple.
Don't put source code in graphics or images. People want to copy and paste the code into their editors.
Allow them to run the code in the article itself. This is not always possible, but useful when so.
Use anchors when possible. People will usually bookmark your page. Providing anchors to specific areas of your post will allow them to bookmark where they stopped reading. Useful with examples.
A light tone is best. Humor is not helpful. Keep the jokes light and out of the source code.

Summary

The summary is the place to add links to additional information, thank those who helped write the post, and add anything that might be useful to the reader. I like to use the following format:

You have now learned about Python's F-Strings. If you'd like to learn more about them, please visit the following links:

- Pep 498, https://www.python.org/dev/peps/pep-0498/

I must thank all of the people who made this post possible. If you need Python development services, please visit yelluw.com and use the contact form to get in touch with me. Feel free to email me at pryelluw@gmail.com with questions.

The format above puts important links related to the article first, all formalities second, and contact information third. I always put the contact information last because people tend to look for it there.

You have now learned how to write technical blog posts. It is something very useful to know because companies tend to hire software developers who can communicate
clearly. It can also be a way to supplement your income. I must thank Stephanie Hurlburt for the idea and support provided. Follow her on Twitter @sehurlburt because she is awesome.

If you need to have technical posts written for you, feel free to contact me through Yelluw's website. You can also email me to pryelluw@gmail.com. You should also follow Yelluw's Twitter account @yelluwmedia and my personal account @pryelluw. I'm also available for short and long term software development contracts. My current focus is on Python, Django, and Javascript.

Software Ants

Pablo Rivera — Thu, 22 Jun 2017 02:31:01 +0000

This post originally appeared on my blog PabloJuan.com

I was busy finishing the post before this one when my wife yelled “Ants!”. These were no ordinary ants. These were fire ants. The ones that bite really hard and make your skin swell up. As a matter of fact, one of them bit me near my wrist and I’m trying my best not to scratch while typing this.

What do ants have to do with software? Let me explain…

A common occurrence in software development is that projects are seemingly going well until they don’t. Everything looks and feels great. Things are getting done. Deadlines are met. Suddenly something happens and all breaks loose.

The ant invasion reminded me of how that happens. They way ants take over your house is very simple. They find the smallest crevice and walk in line until they find food. They then take it back and repeat the process (whoever wrote that algorithm sure was lazy). Ants work twenty four hours a day. Every day. They don’t stop. Once you realize they are there, the little devils have taken over your whole house (and probably bitten you). There were no signs of this happening. You suddenly had ants and that’s it.

Thing is, these ants work in a way that you don’t notice them. They are a process that is running inside your house but you are not really noticing because they are really small. It’s not until they discover food that you are able to see them.

In software, we also have ants. Or processes that operate parallel to the project that end up creating difficulties down the line. These are not project-killing issues, but they are inconveniences that can make a project more stressful than necessary.

What are software ants? The most common one is the team member that does what he/she wants and makes the rest of the team slowly adjust to their preferences. You suddenly find yourself working in some less than ideal conditions without knowing why.

Another software ant is the manager that slowly over time increases your workload and expectations but never takes time to reconsider how these impact your overall performance. Then the manager expects everything to be done in the same amount of time.

There are many software ants and they all have the same things in common:

Software ants happen over time and mostly unnoticed. But when they surface and bite is that you realize that you have an infestation in your hands. That’s when you have are forced to react and waste time doing so.

How do you avoid software ants? You need to pay close attention to your processes and people. I’m not advocating micro-managing. I mean that you must make sure that processes are clear and provide the outcome required. If someone realizes a team member is doing whatever they want then you must have a process in place that produces the outcome of correcting the situation. Same for the manager that adds more unrelated work over time. Your team must have a way to go one level higher and let others know what is going on. Otherwise your whole project gets impacted (and might even crash and burn).

Don’t let the software ants bite you. ðŸ˜ƒ

I'm a freelance software engineer.
Specializing in Python/Django/Flask and Javascript/Angular. 

I'll be available next month for projects. 

Have experience in EdTech, Advertising, Analytics, 
APIs, Banking, E-Commerce, and more. 

Get in touch at pryelluw@gmail.com

Great rates and service.

Liked this article?

Subscribe to my blog and get great content delivered to your inbox. No spam. Ever.

Click to subscribe to PabloJuan.com

Things you can do to contribute to open source

Pablo Rivera — Tue, 11 Apr 2017 00:44:28 +0000

This post originally appeared on my blog PabloJuan.com

The idea of contributing to open source seems to dwell around the all mighty pull request. Everyone seems to believe that contributing to open source is only about fixing bugs or developing new features. Let me say that's not the case.

Over the years, I've learned that there are ways you can contribute to open source that have a really high upside for both the project and yourself.

Write a tutorial

This is so simple and a lot of people out there don't really think about it. Tutorials are crucial for every open source project there is. They help people learn and discover the technology. Maintainers are often too busy to write them.

Writing a tutorial is not that hard. All it takes is for you to use the technology and document (write about) the experience. For a real example that went on to be featured on the front page of a project check out my first Suave tutorial. To be honest, it's not my best work, but it helped the project and maintainers by providing beginners an entry point into working with the library. Win - Win.

Write some documentation

Documentation is hit or miss in open source. The reason is that we all prefer to write code over docs. I get that. You can help improve the documentation of a project and have a really positive impact. A project with good docs is one that has more potential of becoming mainstream.

The way to approach this is to take the project's current documentation and expand on it. There is no need to write anything new if you don't want to. Simply go over the docs and try and improve it. Try to add more examples, write more about use cases, or simply improve the overall tone. You'd be amazed how much people will appreciate these little things.

Make sure to talk to the maintainers before doing so, because they might be pushing some breaking changes and updating the docs soon themselves.

If you write a tutorial, the code you use is typically useful to add to the documentation as well!

Write a sample program

Some years ago, I wrote a sample program for a new API / library project aimed at IoT. The project maintainers were so happy about it that they featured my code on the front page of their project for years (just checked and it's still there). I did not write any docs or tutorials. Just a program that used their project.

Recently, I wrote a sample program for Pybee's Toga (a multi-platform GUI kit). It's not a big program, but it has already helped others figure out how to use the library.

The best thing about this approach is that you don't need to be a writer. Simply share your code with them and post it online for others to find. The maintainers could potentially ask you to add it to the docs or add it themselves.

I hope this helps those of you trying to get your feet wet with open source. These tips are a great way to make a good impression with a project's maintainers and will net you a lot of positive karma. :)

Want to blog? Read this.

Pablo Rivera — Thu, 16 Mar 2017 17:54:32 +0000

Note: This post was originally published in my blog pablojuan.com

OK, so you want to blog. You have something to tell. That's fantastic. But how do you do it? Here is how:

Before you start

Some quick things you have to understand, believe, and realize before starting.

No one will care about your blog. No one. Except maybe your mom. Why is this important? Because this removes the biggest obstacle people face when starting a blog. They care too much about it and try to make it perfect. Not gonna happen without lots of money and help. Realize that no one person will care about your blog. That means that if you make a mistake no one will notice. No one.
You will suck. Badly. How much? Read my blog. I really suck at it. Does that stop me from blogging? No. The only way to become better at it is to do it as much as possible. Forget about using your lack of skills as an excuse. Make improving your skills the reason you are blogging.
You will mostly write for and to yourself. Have fun. Use it as a sort of diary to log what you were thinking at that moment. Forget about what people might say because no one is paying attention.

Getting set up

Setting yourself up for blogging can be simple or complex. I suggest you pick the simple route because it will allow you to simply start blogging.

Go to Medium, dev.to, WordPress.com, or whatever online blogging platform you want and open an account. You can also do a Facebook page instead.

Your username won't matter. Neither will your picture or bio. Don't waste time with that.

Great, you are ready.

How to blog

Alright! You are now ready for the main event. I'm sure you are excited. I was excited. Finally, people will rejoice in my content! They will notice how smart I really am and shower me with all sorts of goodies.

No. That won't happen. Either way, here is how to do it.

Write one short paragraph about something you did today or recently. Did you face an annoying bug at work today? Describe it. No need to sound smart or even detailed. Just write it down as if you were telling a co-worker about it.
Add a title to it. Something like “One annoying bug that drove me insane today at work”.
Hit publish.

Getting over the fear of publishing

Hitting publish is hard. Yes, yes it is. But I found a hack around it. Here is my hack:

Go to your favorite website.
Find some content that you enjoy.
Copy the link.
Write one sentence about why the link is good.
Paste the link into the blog post.
Write a title that describes the content of the link.
Hit publish.

Do this as many times as required. What's the hack? The reason we fear publishing our posts is that we fear being ridiculed or looking stupid. There is no way that sharing a good link will have that response. You will feel free to share it. I sometimes do it in this very same blog. Here is an example.

You will build some confidence after a couple of posts. This will then lead you to writing something short and hitting publish.

But Pablo, I'm a professional. I can't simply publish rubbish! I want to publish long form content.

Great. How much long form content have you written before? None? Well, write the first one. You don't have time? You don't have a great idea? These are all excuses. You either want to blog or not. Find time if you want to. I blog every other night after my daughter falls asleep for 15 to 40 minutes. There is always time.

Do you really want to blog or are you just in love with the idea of blogging?
This is a big issue. Some people love the idea of blogging but hate writing. That's like loving the idea of ice cream but hating frozen desserts. You can't have one without the other. Either do it or stop thinking you will eventually do it. It's not like wanting a car you can't afford. Blogging is accessible and low cost (mostly time). Do it or move on.

How much should you post?

You don't need to publish stuff every day. Once a month or year is fine. No one cares. I write multiple posts on one sitting and schedule them to be released at a rate of one per day. That's me, not you. One post a year is OK. Whatever works for you.

You don't need to be a good writer.

You don't even need to be great at grammar and punctuation. I'm horrible at it. English is my second language. No one cares. Do you know how many emails I've received about some error on my blog? Zero. Zilch. Nada.

Writing is a skill that is only developed by doing. Just like writing code. And riding a bike. Or even making love. No one is awesome when they start doing something. No one.

How do you become a good writer? There are plenty of books and blog posts out there that help with that. But for me, a good writer is someone who cares about what they are writing. Someone who wants to write something good. That's it.

The hardest thing about blogging

The hardest thing about blogging is that you will feel like it's a big waste of time. People won't read your blog for a while. You won't get any happy remarks about your writing. Nothing will happen. At all.

Worse is that you will probably share your posts on social media. Hoping that it resonates with somebody and help them move forward. But no. People in social media won't pay attention either. Well, a handful will. If you are really really really lucky someone with a big audience will like your post and share it. That hardly ever happens.

Is blogging even worth it?

Yes, I feel it is worth blogging. You are documenting your knowledge and experiences and making them available to others. Sharing information is what the internet is about. Without people who blog in spite of being mostly ignored we wouldn't have much of the best parts of the internet. Which is normal everyday people blogging about their passion because its fun.

I hope this was helpful and it pushes you to decide whether blogging is right or wrong for you. Happy blogging! âœŒï¸

10 things I do to keep open source projects healthy and stress free.

Pablo Rivera — Tue, 31 Jan 2017 04:04:39 +0000

What to do when you feel stuck.

Pablo Rivera — Fri, 04 Nov 2016 13:13:18 +0000

Every developer has felt stuck at one moment or another. Sometimes we feel left behind by others. I believe this is due to how quickly things are changing in the tech industry. Rather than fear change, we should embrace it. Over the years I've learned how to turn the feeling of being stuck into a growing opportunity. Here is how:

Work outside your comfort zone

The biggest mistake I've ever done is to label myself as a $language developer. The reason this was a mistake is that it reduced the amount of attention I paid to other languages and technologies. A real example is the Cambrian explosion going on in the Javascript community. I should have focused less on Python and more on Javascript earlier, but I did not. I was comfortable knowing Python, and knowing that the Python marketshare was growing. Over time, I started to feel stuck with Python, because there are things I wanted to do with Python that I could only do with Javascript (in terms of web development). That made me feel like I was stuck. The fix was simple. I started developing my Javascript skills. It took a little bit of time until I realized that the progress I was making in Javascript removed the feeling of being stuck.

You don't necessarily have to learn another language. Maybe you are a Java programmer with Java EE experience. You can work through the feeling of being stuck by learning something new within your ecosystem. Maybe you learn a new unit testing framework. Or start listening to podcasts about Java. Anything that will provide a new and different perspective will do. The feeling of being stuck comes from doing the same thing over and over. We need to vary what we do in order to challenge ourselves and grow. The feeling of being stuck is simply the feeling of halted growth.

Share with others

The biggest benefit I get from using social media and web forums is that I can share with other developers and learn from that they are doing. One great example is Hacker News. I enjoy participating in that community because there is a wide array of opinions and experiences. You might be talking with somebody about a specific technology and the person who built it shows up and joins the conversation. Being able to interact in such fashion is a powerful learning tool. Having conversations with smarter people is a great way to remove the feeling of being stuck. Make sure that your approach here is about listening and learning. Otherwise, you will not benefit as much.

Don't be afraid to fail

I use to loathe sharing my code. I hated it. I knew that people would judge me for it. I'm very insecure about my coding abilities because I wish I was better. Being afraid of what other people might say led me to hide away in a corner. Truth is that everyone sucks at coding. We all do. The best programmers have that one piece of code that will always hunt them. Successful programmers learn that you can only succeed by failing. Good coding skills are the result of bad coding skills being improved over time. Fear of failure makes us feel stuck because we simply close our minds and let our insecurities take over. Rather than let the fear slow us down, we should embrace the fact that learning is a process filled with mistakes. Progress is only achieved when enough learning is accomplished. You must first fail in order to succeed.

Be patient with yourself

I'm afraid to admit that learning this took me longer than I'd like to accept. You have to be patient with yourself. Pushing too hard is not good. There is definitely a possibility of self inflicted burn out. I don't want you to go through that.
How can I be more patient with myself? Understand that things take time. We have to make priorities. I wanted to build lots of robots, but I also wanted to improve my Javascript skills. Rather than do both things at the same time, I decided to work on improving my Javascript skills and let the robot building for later. Setting priorities means that we also have to set goals. Setting goals is tricky. The one thing I've learned about it is that our estimates are always wrong and things will take longer to achieve. Being patient means that we will reconsider our timelines and adjust accordingly. Time is the one thing we don't have and needs to be managed like the precious resource that it is.

I really do hope this helps you move forward. Feeling stuck is not fun and can be frustrating. I believe you can move forward and overcome this feeling if you are willing to give the things I outlined a try. They might not work for you, but you will gain something important: Accepting that you feel stuck is the first step towards getting yourself out of that place.

PS. Follow me on Twitter and Snapchat @pryelluw

I'm available for Python, Django, and Javascript projects.
Contact: pr@yelluw.com

How Bad Software Gets Made

Pablo Rivera — Thu, 03 Nov 2016 16:45:57 +0000

I have worked in many different software projects. Some successful and some not. It turns out that bad software projects have similar traits. These are some I've been able to identify throughout the years:

Poor technical leadership

Chaos and poor decision making does not translate into quality. Good software does not happen by serendipity. It is the result of organization and decision making based on facts. Strong technical leadership also sets the habits for the rest of the team. People learn by example. Technical leaders have to set the example for others to follow.

Undefined responsibilities

People need to know what they have to do. What their basic responsibilities are. Otherwise, they will point fingers and accuse each other when things fail. Its important that we give people the opportunity to do great things. The way to achieve that is to give them opportunities that have a certain level of expectations.

No testing

There is a surprisingly big amount of software being written today without any sort of tests. No unit tests. No integration tests. Not even “does it work on your machine? tests. The code gets written (or copied from the web), compiled, and pushed out. I've seen companies fail due to abysmal product quality that is the result of no testing.

Unwillingness to train

We cannot expect everyone to know everything and to be up to speed on every single technology, so training is essential. A team of developers that does not get trained only grows at the rate of the least trained person. If you pay thousands of dollars a month for a developer, it is worth taking an hour or two a month and train them in some technical subject. Be it testing, coding, a new language, a new paradigm, anything at all.

I think environments that do not promote training comes from the corporate attitude of not investing in their people. They seem to fear that people will leave for better jobs once they acquire new skills. Which happens, but in my experience, is not as big of an issue as they make it seem. Not training someone out fear of them leaving is equal to not falling in love out of fear of being hurt. Open source projects should also train contributors, be it in the form of documentation, a video, or something else. If you train your contributors they will grow and produce better code. The scenario is win-win for both sides. I have only seen a small subset of open source projects that train people. Its no coincidence that these projects are also successful.

Toxic members

Some people are good at writing code but bad at dealing with people. Software is made by people for people. You have to make sure that toxic members are handled properly. Sometimes people become toxic because the leadership is poor (item #1). A lot of toxic people are just burned out. Dealing with toxic people is a complicated subject, but being able to identify a toxic member is enough to improve the conditions for those affected.

Focusing on the short term goals

Pushing code without tests in order to solve a “corner case sounds like a great idea at the moment, but developers must look at the bigger picture. You might have given the OK to others to do the same thing on a bigger scale. Have you ever worked on a project that had tests but now doesn't? Guess how it happened.

What if your project has one or more of these traits? Don't panic. It can be fixed. The important thing to understand is that bad software is a result of things within our control. Knowing and accepting that we can improve things is the first step towards turning around a project.

PS. Follow me on Twitter and Snapchat @pryelluw.

I'm available for Python,
Django, and Javascript projects.
Contact: pr@yelluw.com

Teaching children about technology.

Pablo Rivera — Fri, 28 Oct 2016 13:14:11 +0000

The most amazing experience I've ever had talking about technology has been with a group of third graders. Not with engineers or developers. Not with so called technology evangelists. Not even with the sales guy at Best Buy. It has been with eight year old children.

Every year my daughter's school asks parents to visit the classroom and do a short presentation about their profession. Most people shrug it off and don't attend. But for me, this is an amazing opportunity to get real insight into the future. What people tend to forget is that this is the first generation growing up with a fully functional internet and social networks. This is new ground. There are things that will be invented by this generation that my generation will have never thought about.

Now, on the day of the presentation, I went in with an open mind. Rather than bore them by talking about my daily grind as a programmer, I decided to do a technology Q&A session. No question was off-limits. I stood up in front of a class of twenty eight students and asked what did they want to know about technology.

The first question, I kid you not, was just perfect: How do computers work? Imagine the surprise. Here I am, thinking they might ask some silly questions about robotics, and this eight year old girl asks me about the innards of a computer. I mean, what better question to start with. My answer was fully detailed. I did not hold back anything. Starting from binary numbers and ending with code and compilers. What amazed me is that they were able to follow and understand how it worked. These kids were understanding how a computer worked better than some college level students I know. Amazing.

A couple of questions later a boy asked: What is electricity? The teacher, in an attempt to keep things manageable, told the boy that the question was off topic. I asked the teacher if I could try and answer it and she agreed. My answer was simple: Electricity is the movement of electrons. Electrons are these little things you can't see that when coerced into moving generate electricity. His question to my answer was precious: Like Pikachu? To which I replied: Yes! Like Pikachu! I then went on and explained that electricity is what powers our world. Without it, we would pretty much be living in caves. He had a follow up question that was also amazing: How does electricity power a computer? Why do I need to plug it into the wall? I answered that electricity is what we use to switch transistors on and off. As we switch them in different combinations we are able to do computations. The whole class showed quite a bit of confusion after the word computation. So, I told all of them to raise their hands. Then I told them to lower their hand if they disliked Pokemon. Some hands went down. I then explained that the current state of their hands showed that we had computed the amount of people in the classroom that liked Pokemon. Their response was a class-wide burst of laughter.

Now, my favorite question was made by this really shy boy. He asked: What is a computer virus? My answer was pretty simple: A computer virus is a computer program or app, that is meant to give your computer a bad cold. When a computer gets a cold it tends to lose any or all information you may have on it. He then asked: Why would a programmer create a computer virus if its such a bad thing? I just told him that people do it to harm others. In the same way that the Joker is always trying to hurt Batman. His face lit up and smiled.

The teacher had scheduled fifteen minutes for my session. The kids kept asking questions and we ended up doing a forty five minute session. I was really tired by the end. It was like going to a Google interview, then a Facebook interview, then an Amazon interview on the same day. But it was absolutely worth it. The amount of things I learned was simply amazing.

I wrote this post for two reasons:

I want you to try and do the same thing. Make yourself available to answer questions. Let children learn about technology through you. We often talk about teaching kids how to code, but we don't really talk about how we can introduce them to technology. We assume schools or parents will do it. My experience with people that are not technical says that they cannot do a good job explaining it because they hardly understand it themselves. We need more experts to stand up and simply answer questions.
Another teacher at my daughter's school asked me to do the same thing with his class. This shows that there is a need for people to do the same thing. It also shows a need for educational products in this area.

Thank you for reading!

PS. I'm available on twitter if you have any questions. You may also email me at pr@yelluw.com

I'm available for Python, Django, and Javascript projects.
Contact: pr@yelluw.com