DEV Community: Daniel Golant

Only Debate The Non-Linear

Daniel Golant — Fri, 17 Feb 2023 21:46:04 +0000

I sometimes feel like the course of my career has been one long vacillation¹ between being too argumentative and too deferential.

I’ve often struggled specifically in work contexts to discern when a debate was worth having. In the moment, it has often been difficult to suss out whether my disagreements were rooted in real merit, or simply personal preference, and more importantly whether those disagreements were worth airing.

In fairness to myself, I’ve also come into contact with many other people who struggle with this. I can’t count how many people I’ve worked with who casually made requests for significant changes to other peoples’ work, often for spurious benefit and with horribly inopportune timing. Funnily enough, those are the exact people who I’ve historically avoided debating with, either due to a (often mistaken) belief that they simply knew better, or due to an (often correct) understanding that these people are just not worth debating. I hope that someday my career rewards me for at least thinking about whether it’s worth having certain debates, because it would break my heart to find out that what society really values are those sorts of inconsiderate boor.

nit: hey could you rewrite this entire pull request

— jordan (@jdan) January 27, 2023

Do We Really Have To Fight?

That being said, I’ve just as frequently seen unthinking accession to other peoples’ decisions go just as poorly. I’ve seen this referred to as “false harmony” in management articles, and it can mean that teams fall into bad patterns just for the sake of collegiality. After all, we would still be deploying once a week if someone hadn’t decided to rock the boat a bit.

We know from years of organizational psychology research² that some amount of conflict between people is healthy and desirable. What that “some amount” looks like, and how to attenuate levels of disagreement towards that magic number, is of course the golden question.

Reflecting on my own swings between needless belligerence and deleterious avoidance, I’ve come to the conclusion that whether conflict in a group is at “healthy” levels is, internally to one person, mostly rooted in confidence. People who try to present as supremely confident³ will often seek conflict (or at least domination) in trivial matters. People who outwardly present as low in confidence will often avoid open disagreement, even when they have meritorious doubts about an issue. This can, over time, destabilize organizations.

Not all disagreements are equal, and moreover, not all people react to one disagreement in the same way. Their impact on the morale of both organizations and individuals doesn’t even have any sort of logical progression. Periodic debates over things that are perceived as low in importance can often outweigh the occasional knock-down, drag-out fight over matters that participants feel are critical to long term success. If you re-read the previous sentence, you’ll notice that I didn’t mention the direction of the aforementioned impact on morale. Some people –whose existence perpetually amazes me- actually enjoy discussing linting rules. Like I said, the impact of conflict is highly individual.

You Gotta Fight, When It’s Right

We’ve established that there’s some equilibrium level of conflict, and that some conflict can actually increase the efficiency and morale of a team. This is not some groundbreaking insight by any means. That being said, how do we find that equilibrium? It’s easy to say “pick your battles” or “only argue about the important things,” but what does that mean? “Important” is a completely arbitrary standard! As I mentioned, not only have I had colleagues who have enjoyed arguing about lint rules, commit style, or whether to deploy on Fridays, but I imagine those same people also find those debates to be quite important. Hell, at times I’ve even been convinced that I was wrong, and come to believe that their topics were important⁴! That still doesn’t give me a tool that tells me whether I am generally correct in judging importance. What we need, and what I have been looking for some time, is a razor. Telling people to only argue about important things is actually good advice, if you give them a toolkit to decide what is important!

My Kingdom For A Shave⁵

When I was reflecting on a recent moment in which I decided to stay mum, I managed to distill just such a personal principle: Only Debate The Non-Linear.

At some point in their careers, most engineers come to a realization: we are not rewarded for linear outputs. Most engineers will tell you that the transition from a junior engineer to a senior engineer, or the truly transformational work in our careers, does not come from just crushing tickets non-stop for extended periods of time. Similarly, these transitions don’t come from implementing some n+1 product feature that you’re told is very important. Instead, engineers are most valued⁶, and therefore most rewarded, for non-linear impacts.

“Non-linear impacts” are impacts that don’t just add some incremental value to the company, and they’re not even impacts that, say, accelerate feature output from θ(2n) to θ(6n). Instead, non-linear impacts eliminate whole swaths of work, thereby increasing the output of every individual in the organization as well⁷. As a concrete example, I would rather implement a self-service e-commerce platform for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks. I wish I was joking that companies like this exist, but I am sure you know someone who has worked in a job like that.

Non-linear drag, despite what you might expect, is not what we call a RuPaul contestant who can’t walk in a straight line.

“Non-linear impact” has an inverse, which I have named “ non-linear drag ”. Non-linear Drag is a term I use to describe factors that lead to exponentially decaying productivity over time. Most folks would probably lump this in with “tech debt”, a term I doubt ever really had a lucid definition. I think precision matters when you’re offering people a razor, so I want to differentiate this form of tech debt, which generally involves bad architecture or fundamental technology mismatches, versus things like an increasing support surface⁸. All growing organizations experience increasing drag, even if they dedicate massive resources to minimizing that drag, but certain choices can set the growth rate of that drag on a very bad path.

Putting It All Together

Engineers love to argue over examples while missing a broader point, so if the examples above don’t please you, hopefully I have at least convinced you of the crazy idea that certain decisions can be critical. They can lead to wild success, but they can also cause you to screw up really badly. If you’re unconvinced of this concept, then I don’t know, maybe you should go juggle some chainsaws. After all, what’s the worst that could happen?

Alright, getting back to our point, at this point we have three premises:

Linear impacts and drags exist, and they’re generally the majority of what we encounter
Non-linear impacts and drags exist, and the opportunity to create them is definitionally rare
Engineers receive outsized rewards for the non-linear impacts they create⁹

Coming back to the start of this post, where I was trying to figure out a razor I could apply that was better than “pick your battles,” I think we now have a strong argument for a good rule of thumb: Only debate the non-linear. If there is a strong case to be made that a proposal will create some non-linear impact, then it is worth debating at some length. In cases where there’s really no chance that an outcome will create this sort of massive impact, then I don’t see much point in wasting too many cycles or emotions on a subject. I see this razor as an organizational analog to, or perhaps even a lever towards, the principle of choosing “boring technologies.”

Of course, not all non-linear outcomes are equal, such as choosing a data model versus choosing a linting standard, but overall I think this rule has given me a solid starting point when deciding whether something is worth a lengthy debate. During my recent stint at Carta, I found that their value of “optimizing for the first derivative” played well with this approach. I think if you apply this test strenuously you’ll find that even subjects the community considers always important really can’t generate an excessive return in business value.

I’m curious to hear how other people “pick their battles”, and I hope at least one person finds a more-rigorous-than-average process useful. What do you think, am I tackling this all wrong? Is this obvious to a normal, well-adjusted person?

Footnotes

More realistically, my life
Not to mention millions of dollars in self-help book sales
We say “present as” rather than “are” because, as we all know, often people presenting as confident are doing it to hide insecurity.
I’ve gone back and forth on some things multiple times, like commit messages, and on others (deploying on Fridays) I’ve come to a synthetic point.
Listen, everyone tells me I need to have headings, you can’t force me to make them coherent
Or at least, should be. I have definitely seen my share of feature farms that pay people lots of money to generate negligible outcomes.
I mention increased output rather than “improved efficiency” because they are different outcomes, in a growing business output beats efficiency. This is a critical distinction passed to me by my old boss Dave Hauenstein.
One thing I love is comparing terms I made up with other terms I made up and never explaining one of them. I could have sworn I published something about this years ago, but I guess I have some more writing to do.
It’s worth mentioning: engineers don’t get fired for creating non-linear drag, the company generally sacks the whole team for that

Stop Checking Where You Are!

Daniel Golant — Tue, 20 Dec 2022 02:03:22 +0000

Quick one to get the juices flowing.

I recently started a new job, and I have been starting to dip my toes into reviewing pull requests the last two weeks. I wanted to take a minute to share my thoughts on a mistake I see even experienced engineers make fairly regularly. It seems silly, but it’s a real footgun, and I see it all the time.

Today, a colleague posted a PR for review that included the following line:


if settings.ENVIRONMENT == DEVELOPMENT_ENVIRONMENT:
    <...>

This is a seemingly innocuous line. It is also an operational nightmare. In certain limited situations, it is alright for the program to check its current execution environment directly, but generally you have better options and you should avoid doing so.

The problem here is two-fold, as outlined by @justjake in a great tweet I can no longer find.

Our first problem is that we are coupling an execution decision directly to the environment, when there’s secretly an intermediary logical leap that is being left off the page. Let’s say the above code was part of the larger statement below:


if settings.ENVIRONMENT == DEVELOPMENT_ENVIRONMENT:
    logger.trace.redirect = ‘/dev/null’

Here we see our program checking whether we are in dev, and redirecting trace logs to /dev/null. One might want to do this in order to tame a crazy log stream, or because they don’t have a tracer running locally that can process these logs into something useful. The logical leap I mentioned earlier is exactly that sentence. Why are we redirecting logs to /dev/null? In fact, part of the reason I chose such an odd example is exactly because it is unexplainable without that bit of context. it’s a real head-scratcher of a decision if you see it just like that on its own! How would you do this correctly? Like so:


if config.logging.mute_tracer_noise == true:
    logger.trace.redirect = ‘/dev/null’

Above, we at least get some more insight into why the decision was made. We can read into the flag name a little and understand that the original implementer wanted to quiet the trace logs, not that they didn’t have an appropriate transport available.

It also means that, if our tracer ever gets too noisy (or costly!) in another environment, we can easily go into our environment config files and change the value. Which takes us to the second code smell coming out of the original approach!

Let’s go back to our original formulation, but say that we’ve added a new environment where we want to mute the tracer. Let’s call it UAT. Updating the original code to satisfy this requirement would look like this:


if settings.ENVIRONMENT == DEVELOPMENT_ENVIRONMENT or settings.ENVIRONMENT == UAT_ENVIRONMENT:
    logger.trace.redirect = '/dev/null'

Ugly! More importantly though, it's operationally intensive. If we were adding new environments weekly, eventually we’d be managing a function just to generate this boolean!

This is actually the more insidious aspect of this code smell. There is now implicit coupling of every configuration that depends on the settings.ENVIRONMENT variable. If we ever want to temporarily enable the tracer in our development environment, the correct solution is now not necessarily clear! The correct solution would be to modify our conditional to drop the DEVELOPMENT_ENVIRONMENT, or delete the conditional completely. How many among us could seriously say that we wouldn’t lazily take an alternate approach at least once, by using the debugger to set settings.ENVIRONMENT to “TEST”? Well, now every downstream configuration will also behave like production, including the one that controls whether you drop the database every time the application terminates.

Wait, your dev machines can’t connect to your test environment directly, right?

There’s a few more examples I could cite, but I wanted this to be fast. You should be using your configuration files to do configuration, and only the truly necessary, bootstrap-related decision making in your app should be coupled to the environment directly.

I’ll leave you with one final note: what happens to your environment-coupled configs when the variable you’re checking comes up null? Are you sure all your conditionals are safe? Even if you’re using a configuration file like I recommend, make sure that you have a good strategy for enforcing the presence of default values, and something to deal with confusing and deeply-nested overrides.

Cheers.

Dev.to Review #15: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 13 Feb 2019 17:01:09 +0000

If you'd like to follow us on iTunes instead of waiting for these posts, check that out over here! If you want the direct RSS link, you can grab it here.

Hey all, We have a great discussion about some great pieces this week, as Malik and I got together again to talk about this week's Top 7.

Starting it off, we have "VS Code settings you should customize", which goes over some productivity hacks in VS code. We talk font ligatures, code formatting, and VSCode's evolution.

VS Code settings you should customize

Geoff Stevens for Software.com ・ Feb 6 '19

#vscode #tips #productivity

After that, we move on to ["A Developer's Guide to Getting Fit"], where Eric gives readers an overview on how he managed to lose 30 lbs with intermittent fasting, a calorie deficit, and a consistent workout schedule. Malik and I discuss our opinions on sharing about personal health and how we relate to our work.

A Developers Guide to Getting Fit

Eric Bishard ・ Feb 9 '19

#discuss #beginners #fitness #guide

Next up, in "Code smart, not hard", Miklos provides a list of five tips that developers can use when working on large applications under certain circumstances. Malik and I talk about generalizing those circumstances, and how peoples' different work backgrounds and experiences influence their thought processes.

Code smart, not hard

Miklos Bertalan ・ Feb 6 '19

#webdev #javascript #react #tutorial

After that, we move on to "The 14 habits of highly effective developers (Part 1)", in which Paul touches on several practical code tips, as well as a tip about mindfulness.

The 14 habits of highly effective developers (Part 1)

Paul Isaris ・ Feb 10 '19

#beginners #career #productivity #motivation

Following that, we discuss "SQL Series: From A to Z". Helen covers 26 topics for new and experienced data analysts alike, going over things like window functions, query plans, as well as more broad terms like normalization. Malik and I talk about the value of more people putting their spin on detailed lists, talk about the growth of the community, and touch on some of the posts that caught our eye. This one is particularly worth checking out.

SQL concepts from A to Z

Helen Anderson ・ Feb 6 '19

#data #database #sql #beginners

Moving on, in ["21 Platforms That Serve As A Lifeline to Web Developers"], Nikhil goes over a collection of different communities, tools, and websites that developers (especially in the freelance scene) would benefit from in their day to day life. We talk about Malik's freelance experience, go over some similar tools we like, and our favorite mentions in the list.

Article No Longer Available

Finally, we go over ["20 VS Code Extensions You'll Actually Use"], in which Al goes over 20 VS Code extensions that he finds actually useful, leaving out plenty of nifty, but not that helpful, extensions we've seen before. Malik and I discuss our go-to extensions, and our concerns around tool bloat.

20 VS Code Extensions You'll Actually Use

Al Romano ・ Feb 8 '19

#vscode #extensions #productivity

Do you have any thoughts on slowness related to VS Code extensions? Do you think the VS Code has started growing outside its scope?

What tools and services save you time on the non-core parts of your work?

What are the parts of projects you think are indispensable, that you've ended up needing even in situations when you were convinced you wouldn't? What should people build first when they're rolling solo?

Let us know in the comments!

As always, we're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know here or on Twitter at @dangolant and @milkstarz.

Dev.to Review #14: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 06 Feb 2019 17:15:14 +0000

If you'd like to follow us on iTunes instead of waiting for these posts, check that out over here! While you're on iTunes, feel free to drop a review, we'd really appreciate it - it'll help us grow, and become more discoverable on the platform (Malik made me write this).
If you'd like to see a full archive without clicking around the series, check out this nifty thing that Overcast automatically created. If you want the direct RSS link, you can grab it here.

We're back! Malik and I are here again to discuss this week's Top 7 Articles on dev.to!

Did you follow along with the debate over The Great Divide?

Have you taken apart monoliths? Has it worked?

Are you tired?

Let us know in the comments, or, drop us a line with any thoughts or topics you want to hear discussed at our new email: devtoreview@gmail.com!

This week's discussed posts are:

Why Everyone Is Fighting About CSS/UX and JS

Uli Troyo ・ Feb 2 '19

#javascript #css #webdev #internetdrama

APIs you didn't know you needed

Mikhail Korolev ・ Jan 29 '19

#api #productivity #fun

CSS: From Zero to Hero

Ali Spittel ・ Jan 29 '19

#beginners #css #frontend

What's The Difference Between A Senior And Lead Developer?

James Hickey ・ Feb 1 '19

#career #webdev

How to Breakthrough the Old Monolith Using the Strangler Pattern

Kyle Galbraith ・ Jan 29 '19

#programming #devops #coding

Three Arguments for Why You Should Write More

Marek Zaluski ・ Jan 28 '19

#writing #career #discuss

Retired, Apparently

Burdette Lamar ・ Feb 1 '19

#career #ruby #opensource #github

We're still experimenting with post formats, audio, feedback loops, etc., so if you have any thoughts, feel free to let us know on here, or on Twitter at @dangolant and @milkstarz.

Dev.to Review #13: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 30 Jan 2019 17:33:32 +0000

If you'd like to follow us on iTunes instead of waiting for these posts, check that out over here! If you'd like to see a full archive without clicking around the series, check out this nifty thing that Overcast automatically created. If you want the direct RSS link, you can grab it here.

Did you miss us? After a month long hiatus, Malik and I are back again to discuss this week's Top 7 Articles on dev.to!

This week's discussed posts are:

20 Docker commands use cases for developers

Alex Barashkov ・ Jan 24 '19

#beginners #docker #webdev #devops

Article No Longer Available

I Am Not A Real Programmer

Andy George (he/him) ・ Jan 25 '19

#motivation #career #failure #beginners

Article No Longer Available

HTTPS In Development: A Practical Guide

Kmaschta ・ Jan 23 '19

#devops #webdev #javascript #react

Article No Longer Available

Be careful of the JWT hype train

Darragh O'Riordan ・ Jan 23 '19

#node #jwt #authentication #security

Do you struggle with CSS specificity? Do you think that the use of JSON web tokens why over-hyped? What tools do you think people reach for too quickly, and which do you think should be brought in as early as possible?

Let us know in the comments!

We're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know on here, or on Twitter at @dangolant and @milkstarz.

Conversation with an Author - Ali Spittel

Daniel Golant — Thu, 03 Jan 2019 17:01:33 +0000

If you'd like to follow us on iTunes instead of waiting for these posts, check that out over here! If you'd like to see a full archive without clicking around the series, check out this nifty thing that Overcast automatically created. If you want the direct RSS link, you can grab it here.

~~We're back! Malik and I are together again to discuss this week's Top 7 Articles on dev.to!~~

Scratch that! We're still on break until the 28th, but we did have the opportunity to sit down with one of our favorite bloggers! Ali Spittel joins us to talk about her process, her career, and what inspires her.

Check it out below!

If you want to see more from Ali, check out her stuff at:

.ltag__user__id__38627 .follow-action-button { background-color: #FFF2F5 !important; color: #FF80AB !important; border-color: #FFF2F5 !important; }

Ali Spittel

Passionate about education, Python, JavaScript, and code art.

ASpittel aspittel https://www.alispit.tel/links/

Zen Of Programming

Or on Twitter, for excellent puppy pictures:

Ali Spittel 💁

@aspittel

Blair’s favorite toy is a sloth that looks a lot like @theslothdev!

21:09 PM - 31 Dec 2018

1 12

Dev.to Review #12: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 12 Dec 2018 16:39:42 +0000

If you'd like to follow us on iTunes instead of waiting for these posts, check that out over here! If you'd like to see a full archive without clicking around the series, check out this nifty thing that Overcast automatically created. If you want the direct RSS link, you can grab it here.

You know the deal (or maybe you don't, I don't know, I won't judge either way), Malik and I are together again to discuss this week's Top 7 Articles on dev.to!

This week's discussed posts are:

Style beautiful web pages without writing any CSS. Using W3.CSS.

Corina Pip ・ Dec 8 '18

#css #w3css #html #style

thank u, next: an introduction to linked lists

Ali Spittel ・ Dec 5 '18

#datastructures #beginners #programming #javascript

How freeCodeCamp.org uses the JAMstack + a single API server to help millions of people learn to code every month

Quincy Larson ・ Dec 5 '18

#webdev #javascript #opensource #devops

Optimize Your Programming Decisions for the 95%, Not the 5%

Nick Janetakis ・ Dec 5 '18

#beginners #devops #productivity #webdev

Keep learning, should you invest your own time?

John Hotterbeekx ・ Dec 3 '18

#productivity #career #programming #learning

Different types of testing explained

jess unrein ・ Dec 6 '18

#testing #beginners #explainlikeimfive

Article No Longer Available

Do you have long-term goals that you're working towards? Do you have a good trigger to remind you of them?

Have there been any times you've over-optimized for the 5%? What did you learn from it?

Let us know in the comments!

We're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know here, or on Twitter at @dangolant and @milkstarz.

Dev.to Review #11: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 05 Dec 2018 17:19:04 +0000

If you'd like to follow us on iTunes instead of waiting for these posts, check that out over here! If you'd like to see a full archive without clicking around the series, check out this nifty thing that Overcast automatically created. If you want the direct RSS link, you can grab it here.

Malik and I get are together again and discuss this week's Top 7 Articles on dev.to.

In our first post, "How we reduced our initial JS/CSS size by 67%", Guilherme talks about his experience cutting frontend payload size for Fider, using techniques like code-splitting, lazy-loading, and moving to smaller dependencies. Malik and I talk about image size, the creativity imposed by constraints, and what "performant" means.

In "5 CSS Tips you didn't know you needed", Lynne covers some solid CSS tricks great for upping your game, brushing up, or getting your feet wet. I try to start a flame war about The Cascade and we talk about the value of CSS-in-JS-in-XSS-in-3EB.

We move onto "How to Write a Game in Under 13 Kb While Taking Care of a Baby", in which (Returning Champ) Jaime González... well, does exactly what the title says. Malik and I quite frankly don't give this post the in-depth investigation it deserves, so go read it, because it will be good for you. Instead, we marvel at the idea that someone could actually take care of a baby, talk about games we've wanted to write, and how to fight multi-tasking.

Another Returning Champ, Jenn, walks readers through toxic behaviors she's seen in the workplace, her reflections with leaving fast and never looking back, and various red flags, in "My experience with toxic teams". Malik and I discuss "Culture Anti-patterns", the meaning of the word "toxic", and what a Minimum Damaging Toxicity might look like.

Next, we discuss "Demystifying the Long Arrow 'Operator'". Some Dood walks readers through a very specific way of writing a decrementing loop and how not to be stumped by it, while also explaining that the notation should be avoided since it's a bit misleading. Our discussion takes us to the best Indiana Jones movie (obviously Crystal Skull) and syntactic styles we try to avoid.

User heftyhead keeps us on theme with last week in "Let's talk about an unnecessary but popular Vue plugin" about a potentially needless module import. We touch on importing really small modules, weigh the utility of a module against the risk of adding it, and once again mention Themes.

We finish off with a post from Our Glorious Hegemon, Blessed Be His House, From Whom All Light And Warmth Radiates Eternally titled "On GUI-shaming and a mountain of hot takes". The Singular Voice Of Truth In A World Of Shadows talks about showing appreciation for one's toolchain without disparaging anyone else's. We talk about how different workflows just mean more work for more people, the difference between healthy social pressure and shaming, and █████████████████████ The Infallibility Of The Word Of Our Leader.

We've changed up the formuoli for the last two conversations based on feedback; do you have any thoughts?

Do you have a "Cultural Anti-pattern" that immediately raises red flags?

Do you think it's actually possible to raise a small child, or are we right that it's a myth?

Let us know in the comments!

We're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know here, or on Twitter at @dangolant and @milkstarz.

Dev.to Review #10: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 28 Nov 2018 17:07:30 +0000

Before you get to the notes, I wanted to mention that we are now on iTunes! This means you should be able to catch us in whatever Podcast app you use. We're still figuring this part out, so the newest episode may take a little bit to show up, but you can fill that time by giving any conversation you missed a listen. If you want the direct RSS link, you can grab it here.

Malik and I are back (and better than ever) this week after some time seeing family, as we gather 'round to chat about this week's Top 7 Articles on dev.to.

In our first post, "Useful resources for programmers", Sahil shares a list of great learning repos on Github that... well, we've used the word exhaustive before but this one really lives up to it. Malik and I discuss the value of general and specific content, some of the links we checked out, and why people keep writing.

We move on to "How To Make Python Concurrent WIth 3 Lines Of Code", by rhymes which covers cutting the time needed to make 1000 requests by 7 using only STDlib tools, and the intricacies around concurrent execution. Malik and I discuss concurrency, the value of standard libraries, and languages' cultures around reimplementing standard functionality.

In "The node_modules problem", Leonardo compares the way NPM manages dependencies against his other experiences with Maven, Gradle, and Nuget, and how culture (theme alert) plays into deep node_modules directories. Malik and I link this back to our discussion on STDlibs and our own experiences with bringing in needless dependencies.

Andrew Davis brings us "Showing Kindness while Programming", in which he discusses the basic building block of good culture: individual habits. Malik and I take Andrew's concepts and run with them, and talk about putting empathy into action, celebrating victories, and with whom responsibility lies when communicating.

In "Writing Good Unit-Tests: A Step By Step Tutorial", Elena gives a play by play of steps taken to make sure your tests are robust, from black box, to white box, to questioning first principles, using an example tool that calculates distances across the world. Malik and I talk about the tradeoffs of each approach, how much testing is enough, and how much we trust the System Under Test.

Next, we discuss "5 Fatal Docker Gotcha's 😱 - for new users". Eugene Cheah talks about common Docker pitfalls that he and his company have personally encountered in the past year, and provides options for mitigation ranging from easy to "only if you have to". In the spirit of Eugene's post, we share our own Docker #fails.

Finally, we discuss "A Year Ago I Never Would Have Been Able To Do This, But I Just Built My First Web App. Here It Is!". Jeremy Schuurmans talks about his year-long journey into writing software, and how it led him to produce his first solo project in 7 days. Malik and I discuss Jeremy's approach, his reflections on the influence of his background, and our own experiences with writing solo projects.

We skip "Host's Choice" for the week, but we highly recommend you check out Grigor's post on HTTP/3.

Any thoughts on this week's conversation?

What's been your experience balancing dependency management versus time savings?

If you've rolled a solo project, what were your big takeaways? When does the project "end"?

Let us know in the comments!

We're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know here, or on Twitter at @dangolant and @milkstarz.

What're You Thankful For?

Daniel Golant — Thu, 22 Nov 2018 19:28:39 +0000

It's Thanksgiving here in the US. For many people, it's a day of reflection on our challenges and blessings that signals the coming end of the year.

I've recently really enjoyed the #discuss tag and discussion threads on this site. You could say I am a little thankful for them 🙂. Prompted by Ben, Jess, and Peter's posts expressing gratitude to the community and its sponsors, I am curious to hear the community's response.

What are you thankful for this year?

Feel free to share anything, I don't mean specifically learning, community, or profession-related, I'm just asking in general🙂.

Dev.to Review #9: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 21 Nov 2018 18:47:28 +0000

Malik and I settle into a well-needed quiet week for Thanksgiving as we get together again to chat about this week's Top 7 Articles on dev.to.

WE start off with "Why Facebook's api starts with a for loop" by Antony Garand. Antony introduces readers to a vulnerability mitigation tactic used by Facebook and Google, and how "JSON Hijacking" works.

We move on to "29 Must Read Books For Programmers", in which Blaine Osepchuk details... well, 29 books he has read and why he enjoyed them (and sometimes didn't!). Blaine makes the great point that it's taken him almost 20 years to read these books, and to not orient all your reading towards personal development. Malik and I get into a discussion on genres we enjoy and ones we avoid.

In "SQL Series: All about SQL JOINs", Helen Anderson returns to give readers a visual breakdown of SQL Joins. We discuss the gotchas you can encounter and the lasting value that beginner-oriented material holds for even those of us who've been around the block a couple times.

From another Returning Champ, we read "Dockerizing a Simple Python Process". In the piece, Jess Unrein breaks down what Docker does for developers, and what some common Dockerfile fields mean. Malik and I discuss our experiences with Docker, common pitfalls, and a great writing approach Jess used to make learning something kind of unavoidable in her piece.

In "Portfolio Advice Thread", Ali Spittel creatively flips the script, soliciting users' portfolio sites, and pulls off an amazing feat of endurance by giving feedback on over 50 portfolios. Malik and I discuss our goals when building a portfolio, the never ending struggle to keep them up-to-date, and common patterns and anti-patterns we spotted. Some of our favorite submissions came from Stack Beauverflow, Shannon Crabill, Bea, and Ruth Reyer.

Next, we discuss "Full-time, side projects, learning, and staying sane". Anna Simoroshka shares a candid picture of what the pressure to constantly be learning and building can yield, and gives readers some actionable tips on how to create a stable lifestyle around which they can schedule creative hobbies. Malik and I discuss our values, and efforts we've made to stabilize parts of our lives.

Finally, we discuss "Favourite albums to listen to while coding". Hussein Al Hammad also asks for audience participation, kicking off the post with some instrumental metal album suggestions before opening up the floor to a very active comments section. Malik and I discuss our music choices for coding, give a few recommendations, and I open up about my situational love for Katy Perry. I recommend people look up "Euro Beat Drifting" on Youtube for some laughs. If you're curious to hear one of my focus playlists, check it out here.

Our "Host's Choice" for the week is "Are we Developers helping Google to build an unstoppable monopoly?", a #discuss post in which Sarthak poses the question of whether developers are helping further entrench Google as a part of the general public's lives, and whether that's a good thing. Malik and I discuss which tech companies we feel have a hold on large parts of people's lives, and what impact they could have.

Do you have any thoughts on what makes a good portfolio?

Do you have any tips staying sane while trying to pursue personal development?

Did any of Blaine's book recommendations speak to you?

Let us know in the comments!

We're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know here, or on Twitter at @dangolant and @milkstarz.

Dev.to Review #8: Top 7 Of The Week, Discussed

Daniel Golant — Wed, 14 Nov 2018 17:11:28 +0000

We have a packed discussion about a set of really outstanding pieces this week, as Malik and I get together again to chat about this week's Top 7 Articles on dev.to.

To kick it off, we have "The Three Stages of a Developer", which discuesses the three broad stages and attitudes you may experience as you progress through a career in development.

After that, we move on to "Teaching Functional Programming: Two Big Approaches", where Ed Toro gives readers two broad frameworks through which to understand functional programming, along with a brisk history lesson and some practical examples.

In "Things Nobody Told Me About Being a Software Engineer", the author details a concrete list of practical lessons she learned over her career so far, both technical and social, which spurred a conversation between Malik and I that probably could've lasted a week. Really a must-read.

Moving on, we discuss an interesting new project launched on dev.to, launched in the post "Gitote is out now!", and talk about the value of community-driven projects.

With "The Unix way... or why you actually want to use Vim", we talk about one user's thoughts on the core strengths of Vim and the Unix Philosophy, and how that relates to our previous conversations on composability...

which leads us very naturally into a dense, excellent post on "Exploring Vim", in which the author walks through a brief history of Vim, his own journey with it, and tips on _ starting with it & sticking with it_.

Finally, we discuss "Awesome PHP Resources on DEV 🚀 🎉 🎢", a piece that points you to all the various resources right here on dev.to that you'd need to go from 0-60 as a PHP developer.

our "Host's Choice" choice for the week is "Developer eXperience: error messages", a systematic comparison of the strengths and weaknesses of various languages from the developer quality of life perspective.

Did we say anything completely incorrect or make any mistakes? Bonus points if you find them all.

What was your personal journey into ~darkness~ Vim?

Do you have any reflections you'd like to share from your career?

Let us know in the comments!

We're still experimenting with post formats, audio, etc., so if you have any thoughts, feel free to let us know here, or on Twitter at @dangolant and @milkstarz.

DEV Community: Daniel Golant

Only Debate The Non-Linear

Do We Really Have To Fight?

You Gotta Fight, When It’s Right

My Kingdom For A Shave5

Putting It All Together

Footnotes

Stop Checking Where You Are!

Dev.to Review #15: Top 7 Of The Week, Discussed

VS Code settings you should customize

Geoff Stevens for Software.com ・ Feb 6 '19

A Developers Guide to Getting Fit

Eric Bishard ・ Feb 9 '19

Code smart, not hard

Miklos Bertalan ・ Feb 6 '19

The 14 habits of highly effective developers (Part 1)

Paul Isaris ・ Feb 10 '19

SQL concepts from A to Z

Helen Anderson ・ Feb 6 '19

Article No Longer Available

20 VS Code Extensions You'll Actually Use

Al Romano ・ Feb 8 '19

Dev.to Review #14: Top 7 Of The Week, Discussed

Why Everyone Is Fighting About CSS/UX and JS

Uli Troyo ・ Feb 2 '19

APIs you didn't know you needed

Mikhail Korolev ・ Jan 29 '19

CSS: From Zero to Hero

Ali Spittel ・ Jan 29 '19

What's The Difference Between A Senior And Lead Developer?

James Hickey ・ Feb 1 '19

How to Breakthrough the Old Monolith Using the Strangler Pattern

Kyle Galbraith ・ Jan 29 '19

Three Arguments for Why You Should Write More

Marek Zaluski ・ Jan 28 '19

Retired, Apparently

Burdette Lamar ・ Feb 1 '19

Dev.to Review #13: Top 7 Of The Week, Discussed

20 Docker commands use cases for developers

Alex Barashkov ・ Jan 24 '19

Article No Longer Available

I Am Not A Real Programmer

Andy George (he/him) ・ Jan 25 '19

Article No Longer Available

HTTPS In Development: A Practical Guide

Kmaschta ・ Jan 23 '19

Article No Longer Available

Be careful of the JWT hype train

Darragh O'Riordan ・ Jan 23 '19

Conversation with an Author - Ali Spittel

Ali Spittel

Dev.to Review #12: Top 7 Of The Week, Discussed

Style beautiful web pages without writing any CSS. Using W3.CSS.

Corina Pip ・ Dec 8 '18

thank u, next: an introduction to linked lists

Ali Spittel ・ Dec 5 '18

How freeCodeCamp.org uses the JAMstack + a single API server to help millions of people learn to code every month

Quincy Larson ・ Dec 5 '18

Optimize Your Programming Decisions for the 95%, Not the 5%

Nick Janetakis ・ Dec 5 '18

Keep learning, should you invest your own time?

John Hotterbeekx ・ Dec 3 '18

Different types of testing explained

jess unrein ・ Dec 6 '18

Article No Longer Available

Dev.to Review #11: Top 7 Of The Week, Discussed

Dev.to Review #10: Top 7 Of The Week, Discussed

What're You Thankful For?

Dev.to Review #9: Top 7 Of The Week, Discussed

Dev.to Review #8: Top 7 Of The Week, Discussed

My Kingdom For A Shave⁵