DEV Community: Andreas Klinger ✌️️

Product Hunt - we are hiring our first junior engineer role - and it's remote!

Andreas Klinger ✌️️ — Thu, 26 Oct 2017 18:11:55 +0000

About Us

ðŸ˜»âœŒï¸

Our mission at Product Hunt is to surface great products to the world and help makers find an audience.

We're a curious, motivated group of founders and makers, operating as an 18-person distributed team within AngelList.

We look for self-starters; those with a founder mentality. We ship every day. We embrace bold ideas and encourage experimentation.

About The Opportunity

This will be the first junior role we have on the engineering team (professional experience can be as few as 1-2 years) _and it will be remote (US or LATAM timezone preferred). You should have a product mindset – all engineers at Product Hunt are product people too – and be eager to work on bug fixes, smaller site enhancements, and engineering support duties. You should be someone that likes to ship, has some basic experience across our entire stack (We use React, GraphQL, Rails) and be excited to learn more. You should be proud of your code but knowledgable enough to know how to manage implementation tradeoffs.

Your responsibilities will include:

â€¢ Working with the community/marketing team to increase efficiency
â€¢ Fixing bugs (yes, we have those too)
â€¢ Collaborating closely with designers to ship great products
â€¢ Leveraging research and usage data to iterate on these products

Skill & Qualifications

â€¢ A track record of launching great projects
â€¢ Desire to ship and work autonomously
â€¢ The ability to work with a distributed team
â€¢ Strong verbal and written communication skills
â€¢ An eagerness to work on engineering support tasks (e.g. bug fixing)

The job is remote - timezones that are between westcoast USA/LATAM and eastern europe/africa are preferred

How To Apply

Please apply here https://angel.co/product-hunt/jobs/292573-junior-full-stack-engineer

Please feel free to leave questions in the comments section or ping me on twitter @andreasklinger .

Coding = thinking in several dimensions

Andreas Klinger ✌️️ — Thu, 15 Jun 2017 17:50:12 +0000

"This change should be easy"

"We could a clone on a hackathon"

"We have no time for refactoring"

"We kind of forgot how to ship stuff fast"

Managing codebases = Thinking in and managing of several dimensions:

the file / component (what a it does)
the system interconnection (how stuff fits together)
the product usecases (how users actually use it / domain logic)
the changes over time (legacy / pivots etc)

Note: technically there can be more (infinite) dimensions but i usually stick to those 4 as mental framework)

As your app grows you scale on all of those 4 axes.

Your individual components become more complex.
Your components interlink more (eg to DRY your code).
Your product usecases become wider to a bigger range of diverse customers.

And most important: You make changes over time.

Often radical changes: Pivots. Either in domain logic or technical approach.

Very quickly your codebase becomes complex and hard to manage.

Thinking of your codebase as a 4d cube

For some people it's hard to imagine 4d objects (gee… i wonder why…)

For the sake of this argument it might be easier to visualize a radar chart.

Example used: Wine (dont judge)

While you add to your code you move on those axes and increase the area and thus make the overall area under management bigger.

If you pay attention the shape of your 4d cube stays smooth and the volume small.
But if you "ain't got the time" your cube will have hacks and weird surface areas which, by itself, will create new problems in future.

Managing a codebase means managing how far you move on those axes.

Judging codebases

You can usually walk through a codebase with the same mental model

how well are components structured?
how well are systems isolated and boundries defined?
how well are the product usecases defined and isolated/expressed in code?
how well are changes over time managed? (acknowledged tech debt, isolation, comments, etc)

"This change should have been easy…"

If you are working on a fresh codebase you have no pre-existing surface area to manage. No needless moves on directions you currently don't care about. You can pretty much go straight to the point you want to get to.

Already established codebases are different.

A change in a component might not be easy if you have to move on the "time" axis by fixing other parts of the system. Aka "refactor this legacy first".

A change in a product usecase won't be easy if your system has a lot of interconnections with badly defined boundries.

A fix in legacy systems might not be easy if systems are highly interconnected / tightly coupled.

"…but it wasn't easy"

The next time you feel bad about how long a change needed think about how much space you moved on each of those axes to get anything done.

Also appreciate how much complexity on all of those axes you improved when you touched those parts of your codebase. And be sure that also the next person will appreciate it.

Good comments explain WHY, not WHAT, and 3 more rules on writing good comments

Andreas Klinger ✌️️ — Thu, 30 Mar 2017 11:10:39 +0000

Comments… I know right… What a 🔥 topic to discuss. I hope the servers can handle our excitement…

But jokes aside. If you work daily with code good comments are essential to your productivity in any mid to large sized codebase. Ugh. What a buzzkill…

So let's get to business: Comments aren't additional to a good codebase. They are the codebase.

Here a few tips to enable you to write better comments…

#1 Your comments should explain WHY not WHAT

"Comments shouldnt be needed. Good code should explain itself what it does."

If you assume this you misunderstood what comments should do.

Comments should never explain what the code does. The code itself should.
Comments should explain why it exists, and why it exists in this way

WHY vs WHAT:

Code should explain WHAT
Comments should explain WHY this code exists or WHY it has to do something in a non-obvious way.

Bad:

class Newsletter
  # removes stuff from newsletter
  def remove(stuff)
  …
  end
end

Good:

class Newsletter
  # Note(andreasklinger): In case we run into XYZ we need to remove the user to avoid
  #   problems w/ ABC and DEFG's API. Read more here: https://.....
  def remove(stuff)
  …
  end
end

#2 Leave your name

At Product Hunt we have the habit of always leaving a name next to a comment.

eg:

Note(andreasklinger): This is a comment.

But you can use git blame for that.

People will move code around, People will edit your lines (remove trailing spaces anyone?).
Nobody will bother to find the author once code got moved around or edited often enough.

Especially in smaller teams just the name alone helps you to understand why something exists or if you should bother trying to fix/improve it.

#3 Be thorough

The "next developer taking over" is almost a myth.

Usually the "next developer" is just "quickly passing by" has her own thing she wants to get done and your code got in the way.

Imagine the next person landing in your code to have no context whatsoever and VERY limited time to change it.

While you wrote the code it was obvious to you - it will never be that obvious again - to no-one, including you.

Explain without the assumption that people already know how your system works
Explain the quirks of external systems that you have to consider
Explain the quirks of internal systems that you have to consider
Explain which parts of the system are Legacy
Explain when (eg legacy) code can be removed (leave a "after X is done" or a date whenever possible)
Explain the hacks you needed to do and why they work
Explain the internal interdependencies that arent explicit (eg other systems relying on structure or api)
Be ok w/ writing a longer paragraph whenever needed
Never use external documentation if you can avoid. If it's not in the same file people won't update
Ask to "Leave a BFN" (leave a big f*** note) - expect also your coworkers to leave notes to any code whenever needed

#4 Avoid clutter

Explicit > Implicit BUT you want to avoid explicit when explicit becomes redundant.

Write your comments.
When you wrote your comment read it again and see what you can remove or simplify.

If you can't explain it simply, you don't understand it well enough.

Albert Einstein

Hope that helps!

Comments aren't additional to a good codebase. They are the codebase.
While code makes a complex systems manageable for machines comments make them manageable for humans.

hth,
feel free to hit me up on twitter!

@andreasklinger