
Show HN: A Senior Engineer's CheckList - littleblah
Sharing something that I wrote for my use but I think can be useful to others (I am an engineer with the title of Senior Software Engineer)<p>Visit [1] for a full list (table view gives a lot of options. See &quot;Controls&quot;). 
Visit [2] for a summary.
The source of the list is at [3]<p>1. https:&#x2F;&#x2F;littleblah.com&#x2F;post&#x2F;2019-09-01-senior-engineer-checklist&#x2F;<p>2. https:&#x2F;&#x2F;medium.com&#x2F;@littleblah&#x2F;my-top-25-items-in-a-senior-engineers-checklist-c8e9f9f6e3c2<p>3. https:&#x2F;&#x2F;github.com&#x2F;littleblah&#x2F;senior-engineer-checklist<p>Feedbacks&#x2F;Pull requests solicited :)
======
dbmikus
About this one:

> Respect code and systems that came before you. There are reasons for every
> code and every guard that exists in production

Sometimes there's bad code in prod, or code that doesn't need to exist
anymore. You should try to understand when something is there for a good
reason versus a bad reason. Cut out the bad code, keep the good code.

I've seen a lot of cases where people assume that current code is untouchable
or designed very intentionally, so they wrap it and then you end up with a
tower of abstractions built on a poor base.

So, I think as a senior engineer you should try to understand the difference
between code that should stay and code that should go.

~~~
mgkimsal
The opposite can happen.

Took over a system in Aug '18 with someone else. Previous 'senior engineer'
had left after a year to go be a CTO someplace else. _Everything_ seemed wrong
- bad smells everywhere, spidey-sense a-tinging every day.

In October, we found that code put in place had been _losing data_ since April
- we had 6 months of pure data loss. Data that people assumed was 'working'
because ... they hit a button and looked at the screen, and it was there.
HOWEVER... after the midnight job run, the data was gone. No one ever looked
the next day. Until October, and then it was way too late.

The whole "respect the existing code" has a HUGE assumption in it - that
things are actually _WORKING CORRECTLY_ in the first place. It also _often_
assumes some of the original people who wrote the code you're dealing with are
still on the team and and to answer questions.

THAT particular project above - my gut was "rebuild" \- and we didn't. 16
months later, we are still finding code that is simply broken - data is lost,
things are breaking, etc. But the whole "well, you're just someone coming in
new - all devs just want to start from scratch and you shouldn't do that!"
reared its head, and that idea was pushed aside.

I'd turn it around. Someone needs to be able to demonstrate - usually via
automated tests I'd think - that things are, in fact, working as
expected/assumed. If not, study/understand, then feel free to
rebuild/throwaway.

I've taken part in another project with hundreds/thousands of tests, and while
I hit code that looks/smells weird sometimes, some of the original people are
on the team still, answer questions about 'why', and the tests pass. Even
though it sometimes looks 'bad', it's functional and we can demonstrate its
functional and working.

This is a HUGE difference, and that assumption about "it's working correctly
right now" shouldn't be taken for granted.

~~~
jacekm
I think respect does not imply assumption of correctness. It's more like:
there's a reason why the code looks like it does. The reason could be time
pressure, some crucial information missing at the time when it was being
implemented, etc. By all means try to improve it but don't look down on a
person who created it. It's easy to judge from perspective of 6 or more
months.

~~~
mgkimsal
"The reason" can also be lack of basic competence in previous workers. That
can be extended to the rest of the team or management around the worker(s) for
not providing a guidance/help.

"reason" can be "cause/effect" reason, but also "justifiable rationale". The
files look like they do because someone typed keys and hit 'save' \-
cause/effect. But there's often no justification for how some code exists in
its state that has to do with issues related to the business/logic itself.
External factors - time (as you mentioned) or missing info (as you mentioned)
- that missing info should have been documented somewhere.

 _I_ put out a lot of bad code in my early days. Seniors who came in
afterwards ... yeah, the only or primary reason they could get from my code
was "he wasn't very good at this". And they were correct. I got better, but
primarily through trial and error (lots of them).

In thinking of some specific projects from 98/99 - I was demonstrably not
good. I got stuff done, but it was generally very inefficient. But... it
worked (to the level of understanding of everyone on the project). Even then,
people weren't coming in after me to make basic stuff _work_ , but they did
help make it better.

If you're coming in to a project and there's no unit tests, no sample data, no
repeatable build process, no documentation, no testing or verification
process, and no previous team members to actually talk to to get questions
answered, there's little reason to have any assumption of correctness. There
may very well be 'reasons' for the lack of all of those factors above, but
nothing makes me assume the code is correct. And... if I'm brought in to a
project like that, "respecting" the code or the people before adds no benefit
to the project, and may detract from getting stuff done.

~~~
5trokerac3
> "The reason" can also be lack of basic competence in previous workers.

That type of wording belies a destructive approach to the problem. What I'm
told is "lack of competence" is often someone not being trained properly, or
leadership that decided to make a deadline no matter what, or a junior dev
that got called a senior dev to fill a seat at a cheaper rate, or someone who
knew they didn't have the skills but didn't want to admit it and lose their
job.

The other thing I often find is that regular complaining about other people's
code is usually projection. The less forgiving someone is the more likely that
their code and architectural decisions suck even more than the people they're
complaining about.

There's a senior dev at my job who openly craps on other dev teams as
incompetent - to the point that he literally says, "those guys are fucking
stupid and their code sucks". This guy never documents his own work, makes
inflexible architectural decisions that don't take anyone else into account,
and generally causes hours worth of workaround code for me every month.

~~~
mgkimsal
"often someone not being trained properly, or leadership that decided to make
a deadline no matter what"

> That can be extended to the rest of the team or management around the
> worker(s) for not providing a guidance/help.

I indicated this isn't always/necessarily one person's fault.

re: your senior dev. he might be correct that their code sucks, but he's also
being an ass in his own right.

I've told this story a few times to folks where... in 2017, I was contacted by
someone who said "the system stopped working". Turns out it was something I'd
built in 2002/2003\. It's eye-opening and humbling to go back and fix your own
mistakes from 15 years earlier.

> The less forgiving someone is the more likely that their code and
> architectural decisions suck even more than the people they're complaining
> about.

I don't disagree. It's why I tell people to document as much as they can -
document the meetings behind decisions, document the rationale for cutting
corners. It will help _YOU_ later on when you have to go back and can't
remember why you did XYZ. (See above reference to 2017/2002).

I fully realize my stance comes across as offensive in some situations, and I
do not always project this stance. I'm fully aware people are forced in to bad
choices some times - I've done it myself (on both sides of the table).

However, I'm also _often_ coming in to situations where I have nothing more
than running code and a client wanting stuff done. My scenario above about no
tests, no sample data, no testing process, no documentation and no previous
dev to consult with... it's probably been more than 50% of the projects I've
worked on in the past 20+ years. Clients/employers also read some of the same
blog posts, and will sometimes throw out the "you shouldn't just rewrite
stuff!" line (often while simultaneously telling me stuff is broken but "used
to work 2 years ago"). These are sometimes 'dailywtf'-level projects, and if
the primary goal is to make sure data and processing works as people need and
expect today, large/wholesale overhauls are often necessary.

I've been on a short term project with a team the last few months and this is
100% different from many previous projects. There's 30+ tech folks, I'm on a
team of 8, a mix of jr/sr folks, decent communication, a moderately large (and
up to date and growing) test suite, test data, _some_ documentation (could be
improved), but generally all good people. I've seen some evidence of the "I'm
the awesomest" dev work in the code repos, and those people are no longer
around.

I'm not coming in to this project saying "everyone before me sucked ass and
I'm a dev god". mostly because it's nowhere near true, but the process of
getting stuff done is more team oriented - there's people to help, people to
review, a good culture around the project, etc. There are _problems_ but
nothing like some of the other scenarios I listed above. So... this _is_ the
sort of scenario where it's a appropriate to respect the other folks, previous
code, process, etc - it's all there and there's a defined way of working and
getting better. Not all projects are like that.

FWIW, to the extent I find myself complaining about "other people's code",
it's usually just a prelude to complaining about the processes which led to
it. Why is someone being told to do XYZ without any context? Why are they
excluded from decision making meetings, but given full responsibility for
hitting a deadline they can't possibly meet? These aren't questions for the
dev who wrote the code, but for the project management which led to that.

Example: Was brought in on a project with horrible code a few years back.
Utter garbage - everything was NIH - they'd built everything from scratch.
Digging a bit further, I find out that all dev and server boxes are limited
from hitting the internet. No package managers work for anyone, so they build
everything from scratch. Exceptions could be made - in writing - and within a
few days or week or so, you might have someone pulldown and compile resources
from a 'blessed' connection, then give you that code to run yourself. Things
like encryption/decryption algorithms were being written by hand because it
was the only way to hit deadlines in that working environment. Yes, it's
literally insane to try to work that way, but I had a team of people who all
did that, and felt trapped. It wasn't their fault entirely (excepting that
they should have all just quit at once, or threatened to) but day by day
things just got worse. Poor management was the root, not the devs - the bad
code was just a symptom.

~~~
MasiUnpleasant
> document the meetings behind decisions, document the rationale for cutting
> corners

... document the API, document the project goals, document the company values,
document checklists and routines, document processes and personal
instructions. DOCUMENT THE GOD DAMN HISTORY OF FAILURES AND INCIDENTS!

And then rely in job on all those documents, not on talks and experience or
memory of some key engineers. It hurts when you start, people tend to blame
all those unnecessary staff, but it pays off in so high rates later. Often
it's possible to say if a company will be successful on long run only by
seeing its documentation.

------
Flimm
Here is a clickable list of what the OP posted, for the lazy:

1\. [https://littleblah.com/post/2019-09-01-senior-engineer-
check...](https://littleblah.com/post/2019-09-01-senior-engineer-checklist/)

2\. [https://medium.com/@littleblah/my-top-25-items-in-a-
senior-e...](https://medium.com/@littleblah/my-top-25-items-in-a-senior-
engineers-checklist-c8e9f9f6e3c2)

3\. [https://github.com/littleblah/senior-engineer-
checklist](https://github.com/littleblah/senior-engineer-checklist)

~~~
littleblah
Thanks. Somehow I failed to create clickable links :(

~~~
Flimm
Not your fault. It's impossible to do in the post description.

------
notTyler
'Get involved with hiring for your team and company, and maintain a high bar
for hiring quality candidates.'

Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's
a really big dilemma (extensive hiring process that weeds out good candidates
due to time and frustration or take risks) and it makes it sound like it's
just something, you can, you know, do on a Tuesday in your spare time, and
then on Wednesday you can solve the architecture problem.

And that's pretty much this list summed up. It's nice on paper, and maybe it
will make a difference if someone consults it when making tough decisions.
Thanks for your effort.

~~~
LandR
Especially nowadays when Developers don't seem to have to be required to
actually be able to code.

I'm not part of the hiring process at our place but from what I've tried to
contribute as a potential technical test, I get told it's too hard... It's
really really not hard at all. But from what I can tell if you ask them to
code, even in their own time or in the interview, that's unfair and stressful
and you aren't seeing them at their best. So you ask questions instead of
asking them to code, but then developers don't remember stuff they can just
google nowadays. Again, you are being unfair and it's too hard for them!

We really seem to have allowed the infantalization of our industry, it's very
depressing. Maybe the answer is just reject anyone under 35?

~~~
iovrthoughtthis
I find that things I think would be easy and often incredibly difficult for
people who are not as experienced as I am. That certainly played out while I
was writing exams for undergraduates.

Once we become experts (relatively) at something it becomes very difficult to
judge "easy" and "hard" things. I suspect we have rose tinted glasses about
our prior selves and their ability. Plus, the people we are testing are not
our prior selves and have a totally different set of experiences they draw
from.

You're comment feel very much so "back in my day" which I am almost certain is
a logical fallacy.

------
tmh88j
Thanks for the list. There are a lot of great suggestions here, but I think
the scope is much wider than just senior engineers for a majority of the
items. Here are a few that I think are especially important for junior level
engineers.

• Question everything and ask “why” repetitively until you get to the root of
problems and situations.

• Do not be adamant about your views. Listen to others and accept that there
is more than one way to look at a problem statement, and multiple valid
solutions to a problem.

• Have strong mentors to help you navigate and grow in the company.

• Read a few technical books every year.

• Actively seek feedback from your manager

The bullets above brings me to halfway through the list, and I feel that I was
pretty selective in the ones that I chose. At this point for the remainder of
the list nearly every item is one that I'd suggest for any experience level.

~~~
rekabis
Second bullet point: recommend using “strong opinions weakly held”
([https://medium.com/@ameet/strong-opinions-weakly-held-a-
fram...](https://medium.com/@ameet/strong-opinions-weakly-held-a-framework-
for-thinking-6530d417e364)).

Always be ready to review any opinion you have in the face of new evidence. In
fact, seek out information that will challenge your opinions. But until the
burden of evidence favours another opinion over yours, be prepared to hold and
defend your opinions stridently.

~~~
galaktor
> until the burden of evidence favours another opinion over yours, be prepared
> to hold and defend your opinions stridently

It might seem obvious, but this part is extremely important and can be very
difficult to live by because it encourages (healthy) disagreement and
conflict. "Strong opinions, weakly held" is explicitly _not_ about giving in
to a majority opinion or because the opinion is coming from a position of
higher authority. It's essentially the scientific method. It does not mean you
should agree with other peoples' opinions just because they said it louder
and/or more often than you did.

I've witnessed senior engineers and managers misunderstand this mantra and
(mis)use it to punish ICs who disagreed with ideas of other more/tenured
engineers but lacked evidence for being "better".

If you intend to use this framework as a value in your organisation, make sure
you and everybody else understand what it means (_especially_ your engineering
managers).

~~~
jayrwren
> It's essentially the scientific method.

I had never considered this before and it is right and true.

Thank you for enlightening me.

------
wyldfire
Thanks for sharing. I would instead describe this list as "principles" instead
of a checklist. A checklist is often used for a much more specific scope with
very specific items. These are not applicable to any specific time or scenario
and have activities that are not very specific.

Here's my thoughts on a few of the items themselves:

"Follow the principles of extreme ownership." \-- Unless the term "extreme
ownership" describes something specific (like "Extreme Programming"), it
should be reworded to clarify. What are these principles or what is 'extreme
ownership'? Is it clearer to say "make sure you take ownership"? Or "don't
waste time working on things outside of your domain"? Or "don't limit your
focus to just those items explicitly owned by you"? The latter is approaching
XP's "collective code ownership" / "shared code."

"Be reachable to other engineers" \-- is this like making sure you're
available? Like "check into the company Slack channel frequently"? "Make sure
you reply-all to that 11pm email so everyone knows you were checking your
email then?" Sorry: that sounds a bit cynical but it's easy to misread this
principle that way. Best reword this one IMO.

"Avoid stretching yourself too thin to be effective" \- this is a great tip
but is it specific enough to be useful? How will I know when I've done this? I
think I know the answer but would a junior engineer reading this list know?

"When dealing with politics, avoid it, but have right folks vouch for your
work" \-- this one is not specific enough for me. "Avoid politics"? Who are
the "right folks" \-- how would I know whether I had asked the right folks to
vouch for the work?

"If you are under-utilized, ask your manager for areas to explore" \-- IMO
this works better if you can specifically say "I want to work on X" and bonus
points if "X" is an item that you know contributes directly to high level
goals for the company.

~~~
dancek
_Extreme ownership_ probably refers to the book _Extreme Ownership: How U.S.
Navy SEALs Lead and Win_.

~~~
littleblah
yes!

------
avip
It's a (thoughtful) list for the "senior engineer in 500+ heads company".

If you work for a small startup (where you'll be forced to be "senior
engineer" if you like it or not), you'll have no "manager", "peers",
"projects", "hiring", "mentoring", "networking", and so 95% of the list items
immediately pop.

~~~
arcticbull
If you're at a startup you better be hiring! That's your #1 job! You better
keep that bar high because the next round of folks will be hired by them.
Further, at a small startup you can't get away from a bad hire, they're
literally adjacent to you for 50+ hours a week.

Further to this point, networking is crucial too, but it's more networking
outside the company. With other startups, with other technical folks -- your
hiring pipeline is built on your personal network until you get to at least
20+.

~~~
littleblah
To add to this, I found these resources great:

1\. [https://blog.samaltman.com/how-to-hire](https://blog.samaltman.com/how-
to-hire)

2\.
[https://startupclass.samaltman.com/courses/lec02/](https://startupclass.samaltman.com/courses/lec02/)

------
wry_discontent
> [Reminder] One-on-one usually is not a status meeting

I have never had a job where my one on ones didn't devolve into status
meetings and chitchat. What the hell am I supposed to talk about?

~~~
sbarzowski
1) Feedback (going both ways). 2) Anything that is blocking/bothering you. 3)
How you feel about any recent developments in the team/company. 4) Long-term
career stuff. What interests you, in what direction you want to be going. 5)
Stupid organizational stuff you need assistance with (e.g. reimbursements). 6)
Random smalltalk, personal stuff.

------
timdorr
What is this a checklist of exactly? A list of things to do to become a senior
engineer, or things to do once you are a senior engineer?

There is little description or context to this, so I'm not sure what I'm
looking at here.

Apologies for being dense!

~~~
mychael
It's not your fault. The post has zero context.

~~~
littleblah
Sorry about that. Thanks for pointing out the gaps. I will revisit this list
in some time, and make changes based on feedback. If you can, feel free to
contribute through the shared github link.

------
rukuu001
This is a very good set of principles to operate by.

'Checklist' made me think of something a little more task-focused, e.g.
checklist for reviewing code, checklist for designing systems, checklist for
deployment etc.

So... I love the content, but I'd change the terminology.

~~~
littleblah
Thanks!

------
grumpy8
>> extreme ownership

This is my biggest pet peeve with junior developers. I find there's a total
lack of ownership about making sure the feature is completely wrapped-up (not
just the code, but the tests, the metrics, that it's shipped, that it's
correctly marked as done and communicated, etc.)

I find they /expect/ that someone else at the company will review and make
sure everything is done and safe, rather than be proactive about it.

~~~
crispyambulance
"Extreme ownership" is something that takes time to develop.

It's why chefs-in-training at elite restaurants chop vegetables, mop floors
and perform other menial task for an uncanny amount of time before proceeding
to other things.

It's OK for junior folks to not see the big picture. I'd be FAR more concerned
about heavily silo'd senior engineers only focusing on one thing.

------
arcticbull
These are excellent, except for one, which is to avoid politics. Politics is
the art of making other people want the things that you want. If you can't do
that, you're not a senior engineer. Politics is critical for your success, and
honestly, a large number of these sixty points fall under, IMO, politics.

tl;dr: s/"Avoid politics, but have right folks vouch for your work"/"Become an
adept politician".

~~~
littleblah
> Politics is the art of making other people want the things that you want.

I would say tactical negotiation and leveraging personal connect is healthy,
but manipulation for personal gains at the cost of a larger good is what is my
definition of "politics".

I have seen couple of managers in my career who, while were poor managers
based on employee voice surveys in the company, ended up with large charters
due to being good at politics/"rubbing backs". I want to say that end result
was they screwed it up since their directs ended up leaving their team, but in
reality, they thrived despite losing folks and not delivering projects, again
due to politics. As an engineer, I failed to appreciate that.

~~~
icebraining
> manipulation for personal gains at the cost of a larger good is what is my
> definition of "politics".

I think that's an unhelpful definition; one should avoid conflating the
activity with a particular goal. Politics is governance and decision-making,
and how to convince people to support your position; whether that's performed
for personal gain, or for the good of the company, or for the good of society
(and the three are not mutually exclusive), is another thing.

~~~
littleblah
fair enough

------
chickenfries
> Avoid over-engineering

I would consider this list to be a little over-engineered

------
29athrowaway
> "Understand the business aspect of your work, and what makes money.
> Eventually, only that matters."

How about ethics? company reputation? legal compliance? corporate
responsibility?

~~~
tracer4201
Your post comes off as if the author is purposely avoiding these topics. No
doubt they’re important, but while many software people will look at a
company’s reputation or take ethics for granted (in the sense that of course
it’s important), many software people, especially juniors, don’t stop to think
about the business value of spending X on Y. Everything has a cost - for
example, spending the extra time optimizing your code has a cost. Value is
what you want to produce at the end of the day, not a grand architecture or
extremely optimized code. Those may or may not be a means to an end. That’s
not to say you should ignore ethical or legal consequences. I don’t think
people generally want to break the law.

~~~
icebraining
People generally don't want the company to lose money either. Many ethical and
even law violations happen for the same reason you gave: they don’t stop to
think about it. Ethical and legal consequences are not always obvious.

------
StreamBright
Sounds like the person who wrote worked for Amazon or similar company. Almost
all of this was official Amazon guideline for engineers.

~~~
littleblah
Is it? I did not know, sorry.

~~~
StreamBright
I wrote it as a praise. :) I agree with it 100%.

------
mychael
This is not a checklist. Items in a checklist are either checked or unchecked.
This is more of a values matrix.

~~~
dvasdekis
You can click on items to check or uncheck them

~~~
mychael
Thats not true. You can click an item to highlight it. I've never used a
checklist that used highlighting to indicate it's state.

------
visviva
Normally, this is where I'd chide the OP for using "Engineer" in the title
when they really mean "Software Engineer", but (refreshingly) most of the
items on this list seem broadly applicable to different types of engineers, so
it's not really warranted.

~~~
j05huaNathaniel
Your comment seems pretty elitist. It's clearly implying that Software
Engineers aren't real engineers. I'll admit, not every software developer
designs and builds engines (see definition of engine) but many Software
Engineers, in fact, do. The principles of engineering are simply applied
sciences. Many software engineers have degrees in Computer Science and they
are applying the science. I also know plenty of Software Engineers that have
Engineering degrees as well. So I guess I'm just wondering why exactly you
feel the need to "normally" correct OP? Real question, not trolling. I just
want to to understand.

~~~
ben_jones
But you can't deny there is a pervasive overuse of the label 'engineer' to
cover everything from junior web developers with < 1 year experience all the
way to senior roles at major companies. The label has an important meaning to
non-technical readers and should be used more sparingly.

~~~
imafish
So a mechanical engineer with < 1 year experience should also be called a
junior mechanical developer.. or am I missing the point here?

~~~
richardwhiuk
A mechanical engineer with < 1 year of experience likely has a degree in
Engineering, which has been certified by a professional body. In some
countries that's a requirement for using the term "Engineer".

A junior web developer, with less than 1 years experience might have spent two
days reading [https://www.amazon.co.uk/Sams-Teach-Yourself-PHP-
Hours/dp/06...](https://www.amazon.co.uk/Sams-Teach-Yourself-PHP-
Hours/dp/0672326191) (if that).

Let's not pretend those are the same.

Software Engineering has a history of trashing any benefits of formal
education, and refusing to believe that any of it has any worth.

~~~
imafish
> In some countries that's a requirement for using the term "Engineer".

This is more or less the case where I am from, so I assumed that to be
generally applicable, but no? In that case, I agree.

------
DePro
I was recently trying to make something like this checklist, but categorized a
little differently, with multiple levels of detail, and... extensive.

As above, visit [1] for the end-user version and [2] for the repository.

1\.
[http://htmlpreview.github.io/?https://github.com/dpmm99/deve...](http://htmlpreview.github.io/?https://github.com/dpmm99/developer-
knowledge/blob/master/FIPBYBSDS.html)

2\. [https://github.com/dpmm99/developer-
knowledge/](https://github.com/dpmm99/developer-knowledge/)

------
mansoor_
Being a sceptical c __t, I would say that all of these items in the first list
are shaky at best. "All that matters is profit" is how we end up with melting
ice caps!

------
chasd00
"Understand the business aspect of your work, and what makes money.
Eventually, only that matters"

from link #3 thats coded has high effort, shouldn't that really be a medium or
even low? It should be easy to figure out how projects impact the bottom line
at the senior level. In fact, i would argue a senior engineer ought to be
looking at some monthly sales figures every so often.

------
rusteh1
Great list! Did you/do you work at Amazon at some point? I feel like the
Amazon LPs might have influenced some of these?

------
probablypat
This is great! Thank you for sharing your experience.

I have a couple questions with your notes about politics.

Could you expand on what you mean when you say "fall back to first
principals"?

"If politics thrives due to team of company culture, switch" Could you expand
on this if possible?

~~~
digitalsushi
If you cannot disrupt a perverted culture by introducing a new culture, the
politics of the perverted culture will work against you until you break,
align, or leave. It is not unwise to leave before you break and it is easier
to leave before you align.

------
cadbox1
Did you use a tool to create the JSON or did you type it by hand?

~~~
littleblah
`jq` is great. Initially, I started with excel, which I exported as csv, which
using `jq` I converted to JSON.

Why json and not csv? Strictier parsing by javascript.

------
Mc_Big_G
I would add "Demonstrate discipline in following processes and take ownership
in changing them when they don't make sense"

------
ddgflorida
You have a bug in your CSV export. The header has 5 fields and you export 6.
You are missing "#" as the first header field.

------
socratees
Developer Tune-Up by Neil on Software is a similar categorization of skills
and growth areas. it's worth giving a try.

------
rsashwin
I like the css and theme of your website. Did you design it yourself or is
there a theme of sorts which you adopted?

~~~
littleblah
Thanks. Its "even" theme on hugo.

[https://themes.gohugo.io/hugo-theme-even/](https://themes.gohugo.io/hugo-
theme-even/)

~~~
rsashwin
Thanks for sharing! Really appreciate it.

------
cuongnt3010
(y)

------
jablue
Cool sounds great .

