I've been working full-time as a software developer for almost 2 years
now. I’ve learned a lot. I’ve messed a bunch of stuff up too. The
question I’ve been struggling with is
how do I know I’m actually becoming a better
Over the last couple of years, I feel like I'm becoming a better
developer. But is feeling better enough?
What makes a good developer, IMO?
I haven't worked with or known a ton of developers, but I've
worked with some great ones. Besides the actual code a developer
produces, there is lots that makes a developer great. There is lots
that make a developer great, but here are a few things that I think
make a developer (and people in general) great:
They are approachable. They always have time to help the junior dev
like me and give helpful feedback.
They know how to find answers. Because of this, they seem to have a
super-human ability to know everything.
They volunteer to work on the hard stuff. This leads to them
learning more because they stretch themselves.
They admit when they don't know something.
They are not afraid to admit they were wrong.
Unfortunately, all these things are hard to measure. I think most
people can agree that the easy things to measure (number of lines
written, number of tickets closed, etc.) have little bearing on
whether a developer is great. So that's where I get stuck. I want to
get better, I know what I think a good developer looks like, but how
do I know I am better than I was a week, a month, a year ago?
Can getting better be measured?
I like numbers. They are easy to compare. But how do I compare
something like being approachable? I could maybe find a number to
represent it, like number of questions I get a day. I could ask people
to give me a rating on how approachable they think I am, but I'm
guessing the people who like me would rate me highly and the people
who don't would rate me poorly, and that it wouldn't change much over
Let's assume I do find a number or a couple numbers to represent
approachability. Over time, I think I would subconsciously, or maybe
even consciously, find a way to game that number. I'd want to chase
that good feeling that comes from seeing a number improve. My point
is, numbers probably won't work very well. Are all metrics bad? No.
Are most? Maybe. It's hard to find the useful metrics. But they do
exist, I think. But I also know from personal experience that it is
incredibly easy to focus too much on the number and not on the end
result the number is supposed to measure.
So, is feeling better enough?
I'm now thinking yes, just feeling like you're a better developer is
The hosts of one of my favorite podcasts,
talk about yearly themes. Instead of making yearly goals or
resolutions, they have a theme. Whenever a decision or opportunity
comes up, you can just look at your theme determine if the decision is
on or off theme. I think a similar tactic can be taken with becoming a
better developer. Instead of creating specific goals or measuring
(pointless) metrics, just keep what you think makes a developer great
in mind, and when situations arise, just ask, "How would a great
developer act in this situation?". Sounds cheesy, I know. But
that's the best I can come up with right now. It's not just wanting to
be a better developer that makes someone better. It is knowing what
you want to be like and acting more and more like that until you
If you have any ideas or thoughts, let me know. I’d appreciate it.
This is all still forming in my mind. What do you think makes a
developer great? How do you know that you're getting better?
A little bit ago, I finished my first project for a client,
totalpowerandfoam.com. It’s a simple single page landing page.
Here's what it looks like:
I really tried to give it a clean professional look without being too
boring. Early drafts of the site were way too boring. But by adding
shadows and a hero image, I think it came out looking real nice.
As always, hit me up on Twitter if you have any feedback. I'm
definitely learning as I go.
At ng-conf, John Papa gave a talk on writing readable code. You can
watch the video
I recommend it.
Writing clean, readable code seems like an obvious and simple thing to
do, but this talk made me realize that I have been ignoring it. For
whatever reasons (I'm guessing the thrill of increasing my throughput
🤓), I've been focusing more on closing tickets than writing good
code. Recently, I have really been trying to focus on writing quality,
readable code. I've come up with two general steps to help me when I'm
working on an issue:
Just fix the issue or get the feature working.
Go back and clean it up.
I've been stopping after step 1. This has produced some code that I
definitely don't want to go back to. Ever. Now, I've been trying to
slow down and worry less about getting lots of bugs fixed. Instead I'm
trying to figure out what it takes for me to not only complete a
ticket, but complete it in a way that I'm proud of the code I'm
producing. Luckily I work at a company that doesn't pressure me to get
more and more tickets done all the time, so I'm able to actually slow
Recently, a couple of my coworkers and I have been pushing for more
code reviews on our team. I've found this a very effective way to help
me write better code. When I know for sure that someone else is going
to look at my code, I put more effort into making it readable as I'm
working on it. So, code reviews. Do them. Even if it's just with
For me, focusing on readable code is like switching keyboards: my
"productivity" has dropped, but I'm sure it'll pick back up
as I get used to it.
I have found that it is okay to slow down, and that I need to. I have
felt that focusing on writing readable code has been helping me become
a better developer. Next step, make git commits more often.
Hit me up on
if you have and comments or good tips on writing readable code.
A template reference (I'll call it a template ref) is basically a tag
you put on an element in your template so that you can easily
reference that element later. Can you see why they named it
like they did? The syntax is # and then the
name. For example, if I want to add a template ref to an
email input and call it email, then I would add
#email to the input, like the following:
So how is this useful. Well, elements with a template ref can be used
in a template just like a public variable on a component can be.
So if I want a button to validate the email entered, I can do
The value of the email input will be passed into the function. Cool!
In a little project I was working on, I had a widget selector and a
button to add that widget to the page. The button called a function on
the component and needed the selected value from the selector. I could
add a variable to the component and change that every time an option
was selected, but nothing else needs to know about that selected
option, just the function the button calls.
If I select "Tickets" "1 Column" and "2
Rows", then click the button, a,
span-col-1, and span-col-2 will be passed
into addWidget! I like that a lot. It keeps my component
cleaner because I don't need to define a bunch of variables to keep
state that I don't really need.
Template Refs and Components
You might be asking yourself right about now, "Can I only put
template refs on regular ol' HTML elements?" Even if you aren't
asking, the answer is no! You can put template refs on components too
and access their properties! For example, if we have a
hello component that has a property that tells us how
many times a hello world has been done, you can access it in your
template with a template ref.
So there's probably some cool things you can do with that. I haven't
messed with it much.
Template Refs in components
The other powerful way you can use template refs, is grabbing template
elements inside of your component. Using
you can grab an
using your template ref. This lets you do some cool things.