I've written about
getting better at development
and while I don't know what traction that post got, It doesn't matter since I
think it won't hurt to write another one
We'll be talking about a few things here,
A very simple concept that I did write about a while ago but it was more of a
rant than an explanation so let's go through it again.
Your dev environment may not be the most optimal one out there and will always
have things that can be improved.
I personally depend on the terminal a lot even when my code editor can do the
same tasks by adding a plugin and I should get used to using the code editor but
then there's a conflict where I change my editor quite often. I shift from Vim
to Sublime, Sublime to VSCode, VSCode to Vim / Sublime,or try a new code editor
its a never ending cycle, .
While this looks like I'm going to contradict my own point, the reason to go
ahead and master you environment doesn't always include mastering the tool you
use but being able to move freely and quickly through the most used things but
in cases where you are using a tool a lot, make sure you go ahead a become a
power user. Why?
Let's take an example, git is very common tool today, but the max I see people
use it for is
That's all they know and never go curious as to what other options they have,
like you don't have to go through the whole progit book or read the entire
git-scm doc,I'll still link it in case you do want
too, but at least try to figure out how much more powerful git can be, you can
manipulate history, you can manipulate commits by travelling back in time! but
then people are stuck with just Pull Requests on the Web portals instead of
learning how to use patches.
And I get it , not everyone's workflow involves using all this, but everyone has
been at a point where they want to not commit a file but don't know how to
unstage a file they accidentally staged, the answer is
git reset <filepath>.
git restore --staged <file-path> if you've got the newer versions.
But you wouldn't know that unless you actually went ahead and got curious about
what all the tool you are using can offer. The same applies to the code editors
you use, the Database GUI's or even source control tools you use. For the
longest time I've used sourcetree from atlassian for handing projects and
commits just because I like their differ UI , started using Sublime Merge
because of the same reasons and the merge conflict handling of sublime merge is
amazing, though I hardly get conflicts on personal projects (cause I develop
alone, not cause I'm that good!) but the tool comes handy when working with a
team from work, still I prefer going ahead and referring the git doc every now
and then to see any new sub command addition or checking what other commands I
This helps me decide if I should do a normal squash or a fixup on commits in my
There's a million reasons to learn the tool properly but just take this one.
Learn it to improve your own skills and not wait for it to become a
requirement you get from projects.
I really don't have to get into detail here but learn to use a terminal editor,
it can be emacs,vim,nano anything! The same as above applies here as
well, learn how to extend the usability,learn as many keyboard shortcuts as
possible, learn how to modify configs to better match your workflow, as a
minimalist I can work from just the ctrlp plugin and vim for basically
everything, doesn't mean I shouldn't know what other plugins I can add to
improve usability and speed of dev.
A coder with a good typing speed is definitely a plus but that and being able to
move around vim/emacs like it's no big deal for you to manipulate text is an
amazing skill to have, you might get a lot faster by being able to just do that.
Two simple reasons to learn on the above.
Enough about tools and things to learn, let's see how you can improve your
project building mentality. The simple answer is prototype it.
The detailed version though.
Build something with the sole purpose of testing the idea, not with the
mentality of perfecting it. This is to
All these come naturally once you have written a prototype version, where things
aren't built to be perfect but to test the idea. You can also test the market if
you've built something that doesn't exist out there and you want to check the
attention, again doesn't have to be perfect it's a prototype after all.
The point is, now after building this, you have enough idea as to things that
are required, things that work, things that are iffy and conflicts in thought
that you need to be aware off and finally the base scope of the project is now
Next Step? Rebuild it from scratch while keeping everything in mind or refactor
the code to match all of this, both these approaches have their own issues.
We'll start with the easier one, refactoring the code to now be well structured
and you add or remove services,tech,code to accommodate the new requirements
and be a little more robust for later expansion, if you've been doing this
enough, chances are the initial prototype already followed your general
scalability in mind and this is a very easy phase for you.
Chances are you already knew that the language you are using is perfect for the
usecase and you have a good idea of what is needed from the start and the
additional requirements you figured while building are just hiccups and not a
huge pain to fix.
This is hard to do for a lot of people but you can always start from scratch
once you are done with the prototype though this approach needs you to make sure
you understand why are you starting from scratch?
If you say yes to two or more of the above, it's better to start from scratch.
If there's a better stack for it you should definitely pick it up and setup a
solid base for the project , which will be good for the long run. If you need to
change the language all together, then well it's easier that writing interop
code that will need a lot more maintenance while you're doing the migration plus
you end up breaking and fixing a lot more than needed.
A lot of devs wouldn't want to start from scratch because
Either way, use your best judgement or ask people for an opinion on what they
would've done, the point is, always prototype before building the real thing and
know that you might have to scratch it or heavily refactor it to make it a
polished product which can then be pushed into the market.
A non-prototyped product is going to have more failure points and patches than
one that was built again while keeping all of it in mind.
Keep an open mind to learning and that's about it for now.