markdown guide
 

I Google almost everything because I don't remember the APIs, just that there is a way to do it.

 
 

Seems to work out for many React ⚛ devs.
And that's what's recommended by Dan Abramov 😛

click on the link in Dan's tweet

 

I'm with you on this one...
I've been working in a particular platform so long that I've recently began to wonder if I actually still know how to code or whether I've just become particularly skilled at rearranging various snippets of code.
Whatever it is - the one thing I know for sure - I'm reasonably gifted at articulating my problem in a way that I can (usually) find the StackOverflow answer to solve the problem

not sure i know how to code

 
 

Hah. Everybody does this, so much so that Google actually put in a recruitment ad for people searching certain programming related queries.

 

I rely on my IDE autocomplete so much I sometimes forget the standard library

 
 

That's not per se bad. Knowing a solution exists and looking it up is way better than solving a problem you shoudn't have to

 

I'm scared of contributing. I'm afraid of finding out that I'm incompetent so when I challenge myself to find a project to contribute to, I end up scrolling on github until I run away. Dare try to talk me into any, I have more excuses than gifs in @ben 's portfolio 🤣

 

That was me for years, and now all my code is out there for the world to see. 😳

 

This was totally me a year ago then I found some things I REALLY needed fixed in a few gems and that is what pushed me to finally do it. That first PR was SO stressful but I did survive and it has gotten a lot easier 😊

 
 

Do I need ruby to do so? I'd need to brush up on it a lot

The backend is in Ruby and Rails, the frontend is in HTML/CSS/JavaScript/React/Preact. The documentation is in English :P

You could submitting a bug report, submit a feature requests or reading over other pull requests to make sure they make sense and that still counts as contributing 🙂

I think with also this approach, I'll understand the 'why' . The 'how' is always the easiest

 
 

I console.log() things more often than setting a breakpoint and hitting the debugger. Working on it.

 

There's nothing wrong with println debugging! While breakpoint debuggers are a great tool, it is really hard to use them well in async code, which is where good logging is an absolute must! And sometimes, it's just faster and easier to print logs instead of stepping through line-by-line

 
 

I never practice TDD, I always write tests after I write the code. It just seems faster and easier 🤷

I also am not great with linux, I have to google simple command line commands all the time. I'm working on it though!!!

 

There are many who are of the view that TDD hampers productivity and doesn't properly map to the way most teams build software.

Most of the time, the spec isn't 100% set in stone, so there isn't much of a point in writing tests for things that are just going to change anyway. Maybe you could argue that it's worth it later when a product is almost ready to ship, but by that point in time you've probably already validated that most of the things you care about work the way you want them to.

Not everyone is shipping software to fly rockets to the moon. All this testing is overkill and runs counter to the creative process

 

I agree somewhat. A year on a team that does TDD has taught me when and where it is a great tool. No tool is useful all the time and everywhere.

  • Productivity isn't just this sprint. It is the productivity of the next 10 years of maintaining code.

  • Testing is complex and it will take teams time to ramp up from "testing what they know how to test" to "testing where it is needed".

  • Enterprise rarely has top notch code quality. When the devs are a rotating cast of various experience testing TDD keeps the tests flowing. Testing keeps devs from quitting, users from bad experiences and, ultimately, costs down.

Yeah, so to clarify I am certainly on board with unit tests when used where they give you the best bang for your buck.

But I am not in favor of what I think TDD represents, which is this idea that we can't write a single line of app code until there is some automated test for it. That is what I believe hampers productivity.

There is a finesse to finding the right the granularity. The first test you write could take 20 lines of logic to turn green. I've found most tutorials use too many tests and too fine a granularity.

100% branch and line coverage isn't useful and hampers productivity. Getting tests done as you code does not.

 

TDD only comes natural to me when it actually improves my productivity, which happens around 10% of the time.

TDD is helpful when you are writing pure functions which the result is predictable. For example, if you are writing a function that uses Regex to transform a string, it is much easier to TDD it until it works than running your entire system on every change until it works.

 

I do hybrid testing, mostly after, sometimes TDD

I used to preach it but like all methodologies, it doesn't work all the time and requires a lot of discipline.

It's probably counter intuitive but I did a lot more TDD when I was a total noob, now I trust myself more. I have a mental map of most of the tests I have to write for the feature I have. If they are too many I write them in the ticket or a text file or whatever.

I think TDD shines with refactoring, more than for new features

 

TDD is incredibly unintuitive and the majority of developers do not use it.

It is a great skill to eventually take to IMO. But there’s no rush. It’s someyhing worth casually nibbling on until you find places it really clicks.

 

I usually write my code first, add unit tests for new features/bug fixes, and then rely on my code coverage tool to tell me where I need to have more tests.

 

Half my commit messages are "git commit -m 'Doing stuff'" :D

 

git commit -m "random shit"

git commit -m "i don't even know"

git commit -m "stuff"

I'm in the same boat.

 

This is why squash and merge is a godsend; intermediary commits can reflect anything from adding features to removing extraneous spaces that crashed the linter in CI, what counts is the sum of them all (and hopefully a descriptive message attached to that bundle).

 

Hahaha! So you've been doing just Frontend huh?

 
 

I've been preaching functional programming for several years now, and I still don't even grasp all the concepts.

 
 

We (FP programmers) are great at making it not very understandable.

 

I think if you go down the rabbit hole of CSP, monads, combinators than it really gets trick but the basics are simpler than some people make them to.

You don't need to have a "pure" functional language to take advantage of it.

Use functions without side effects, pass functions as arguments (you do this all the time if you work with JavaScript and callbacks), envision your code as a series of composable operations instead of telling something to change state.

It's perfectly fine if you don't do it all time, or ever :D

Chances are you're already doing without knowing it.

 
  • I use GitKraken instead of command line git. I just like being able to visualize everything I'm doing at a glance. And no fat-fingering risk.
  • I still just console.log() stuff.
  • I never write tests. 99% of the time, I'm solo'ing it and making something relatively small and uncomplicated, so I just don't bother with it.
  • I will definitely press up in the terminal 20 or 30 times to avoid typing a long command again.

You know, none of that was too bad. I feel like less of an imposter writing it out. 😊

 

Run

git config --global alias.tree 'log --graph --full-history --all --color --date=short --pretty=format:"%Cred%x09%h %Creset%ad%Cblue%d %Creset %s %C(bold)(%an)%Creset"'

Then

git tree

The Git built in CLI visualizer for git history. :D

 

Regarding the terminal... get fzf and integrate it into your shell. Then you can type CTRL-R and fuzzy search your history! Super great.

 

I'm pretty bad at asking questions. I'm definitely more comfortable digging through the mire of docs and source code than reaching out for help.

 

I still feel like my dev lingo knowledge is 2 years behind my actual knowledge and every time I am talking to someone I will never stop and ask what a word or abbreviation means. Instead I make a mental note, then after the conversation sit on google for 5 min figuring out what they just said and having ah-ha moments 😂

 

I think "I could ask but I need to do this by myself" and then I waste hours searching. I don't want to bother others when they are busy

 

I do this. I worry about whether not knowing an acronym will make me look stupid.

 

I used to be reaaaaallly bad this way. I’ve become more comfortable asking questions over time.

 

I spend way too much time thinking of every edge case and how things will scale. That tends to slow down my coding tasks. And I have a lot of coding work on my plate.

 

I’ll start:

  • I still kind of suck at git
  • I tend to ignore my linters

Things I continue to work on, but not my best coding qualities. 😋

 
  • I do not do git rebase as often as I should
  • I do not commit often enough (usually once for big chunk of work)
  • I tend to find every minor security issue (i.e. possible attack vector) and have a long discussions about it with my team
  • Sometimes I am "It works on my machine" guy and require more evidence / documentation about potential bugs
  • And in the end....I could really be a better developer :/
 

I’m a safe and cautious git user and I tend not to mess things up too badly. But I rarely have a good idea of how to get out of a mess without too much collateral damage.

I sometimes have tendencies to push to origin/master...which is, sadly, locked.... but by me, haha, so when I'm on the roll, nothing will stop me!

 

I'm with you linters. I tend to get annoyed by them. They often lead devs to focus on really pedantic problems. With linter indoctrination, you'll be looking at another dev's code and think "Oh they used an if statement to assign a nullable value instead of a ternary statement. They should fix that." Instead of "the overall maintainability of this code looks good."

 

I joined this year's Advent of Code but it's being pretty hard for me since day 3. I'm very good making websites, CMS, API's, objects/models, tests, all that stuff... But I suck at simple math operations or simple problems without objects 😭

 
  1. I hate the whole Javascript tooling (the fact I'm doing a lot contract work as a Fullstack Developer doesn't help).
  2. Sometimes I miss Java.
  3. I don't like Bootstrap.
 
 

A single 4,751 line PHP file with mixed PHP, MySQL, HTML, CSS and JS is currently running in production for the last 12ish years on a shared hosting service.

The thought of maintaining this app scares the shit out of me, but luckily it's been running smoothly all this time.

 

I can't code unless my text editor has a blue background.

 
  • I hear and say "that's a great candidate for TDD" and never TDD it.
  • I have a tendency to want to work on smaller, less significant things.
    • Sometimes I make mountains out of molehills. 🙈
    • This also makes it hard to see the forest instead of the trees.
  • I force push A LOT, and rewrite my git history A LOT -- usually with git commit --amend. Less so now that GitHub shows force pushes. 😬
  • I tend to do things manually more often than spending the time to automate them.
 

No shame in --amending; also no shame in re-writting the history...just don't do it after pushing to a remote :fire_eyes:

 

4 years as a web developer and I
-still hate JavaScript and all it's frameworks
-everyday I hear about machine learning, artificial intelligence, block chain and still don't know anything deep beyond the superficial
-yet to contribute to any open source because I still suck at coding
-still not used to tech jargon
-still watch video tutorials to learn sthg new quickly, then later dive into documentation much later

...got a lot to improve/change 😭

 

Even after closing in on 10 years of being a professional developer I'm too insecure to share anything substantial in this post.

 
 

I have a habit of googling for someone I don't know how to do and finding my own blog posts because I learned it, did it, wrote about it, and completely forgot about the entire experience. This has happened on multiple occasions.

 

I do the same. I wrote a blog with some solved problems so I can have it at hand.

 

I spend too much time trying to guess what's wrong with my code instead of just debugging right away and realizing I flipped an if/else condition.

 

My first real computer program was written in Basic on the C64; tic-tac-toe.

  • If human went first, the round ended in a tie
  • If the C64 went first, it would win ....it took me the better part of 6 months in middle school to get it to work.
 

My dad first introduced me to programming by helping me make tic tac toe with Visual Basic in Excel. We never finished it, but I went back and did it with Javascript a while ago.

 

It is impossible in the 3x3 grid to win by setting the first marker, the opponent player can always force a draw - although in second position against an optimal player it is also impossible to win. So, your game might have won easily against opponents with a non-optimal strategy.

 
 

I am so bad at async programming. I'm reading through the You Don't Know JS book about it but I have to read every chapter two or three times to get a grip on the concepts.

 
 
  • Some days I think I'm a better programmer than I actually am and other days I think I'm a worse programmer than I am
  • I fall asleep inside my head anytime someone talks about Kubernetes
  • Competitive coding puzzles are not really my thing
 

I use console.log() all the time, I don't plan to stop, and I leave it in server side production code when I use firebase.

I think going out of the way to through a debugger is pretty much admitting you don't really know what you're doing and just need to official about it.

I admit I'm probably wrong about of all this, but throwing my variables into console.log({}) and converting them to an object with the vars name on the fly is just too addictive.

 

I've made it up as I went along. I really don't know much about formal CS (despite nearly 20 years of professional development experience) - I've never really studied it. I feel like a fraud most of the time.

Oh and on one job I lost the company $100k in my first week on the job.

 

I'll often get really excite about a new technology or language, seeing it's potential to help my career. Then I'll hit a roadblock early on and give up way too easily.

 

Well this one took off - I guess catharsis is a good thing, here's mine:

I'm addicted to the teletype-induced Unix shorthand, that is: rm vwls, and I get all OCD about my variable names being the same length to make the code look pretty at the expense of readability. Four character names (without vowels) seem to be my favourite.

Luckily my PoCs tend to get burned down by professionals before production!

 

When someone asks me for help and I can't figure it out I use stackoverflow solutions

 

I've recently been working on this, but I too often take a get-in/get-out approach and forget to take a step back and consider the big picture.

Up until recently I didn't understand Test Driven Development at all and thought it was crazy. I'm still not fond of unit tests where I'm trying to fix a bug, and I have to figure out why the unit test is now breaking.

 

I start coding hoping that the solution comes to me as I go along. This leads to comment stubs everywhere of Just do this here without actually knowing how to do it. I usually just make an empty function with the return value I want in the meantime

 

That's similar to the first step of TDD :D
Writing a failing test with the expected return value

 

My second confession, I don't write nearly enough tests, so I don't know if this makes me feel more or less guilty 😂

 

Sometimes I overthink the smallest task, making myself slow. is this correct? Can I improve it? Is there any better way? Am I using the correct standard? it's updated? and I spend hours reading, searching.

When I code I try to finish a process without performing debugging and in the end perform tests "ohh run to the first time"

I try not to memorize things because I think they will change it later. So I'm dedicated to remembering how to search it in google. Too many frameworks.

I still depend on google and stackoverflow. And although I know English, I still look for words that I do not understand in Google translator.

 

I have no idea what dependency injection is and why I need to know about it.

 

That's because many people who explain it are clueless as well and tell you some overcomplicated bullshit. Actually it's quite a simple thing, not much more than programming against interfaces instead of implementations. You should know about it because it simplifies unit testing. Once you got this, you will find other benefits.

 

I like how IoC takes away the responsibility of layers to know about the creation of other layers (or their scope). Via DI, my controller can have a repository object injected by the IoC container, and the controller doesn't have to manage the lifecycle of the repository object.

Also, in unit tests, the repository object is easier to mock because I don't have my controller creating the instance in a constructor or something my test doesn't have access to.

DI can make things harder to read if the framework is limited to injecting interfaces and the interfaces have several implementations.

 

If you understand the difference between composition and inheritance in OOP you understand dependency injection, the rest is lingo to make it sound more complicated than it actually is

 
  • I started coding on the CMD
  • I am a noob, big noob in Git
  • I don't like to use CSS frameworks
 

I'm addicted to black magic. I'd rather spend two hours on a metaprogramming solution than 10 minutes on a straightforward solution.

 
 
 

I too often have to go back and fix typos I find in docs, comments, or strings because I forget to proofread.

 

I write all my scripts in D because I hate all other scripting languages.

 

More of an OPS confession, but I don't really like AWS. Sure, it's fine, but so much of it is overly complex and unnecessary for 90% of the folks/cases that want to use it.

 

I say I love testing, but I don't do it on a lot of personal projects.

 

I don't know if rebase is better than merge or not.

 

While I've been pitching Docker to my boss every since cgroups were introduced (a long time before Docker), I still don't understand how I could use it in practice

 

I'm hoping I can skip Docker as much as possible altogether. Not that it isn't important but there's a lot of hype. We went from "maintain your own server" to push-to-deploy (AppEngine, Heroku, AWS Elastic Beanstalk) to installing sofware over and over inside containers, to me it feels like a step back in terms of abstraction.

We need to move forward again.

Docker and k8s can be building blocks for that "future" but the same way we don't need to re-code every abstracted layer our apps sit on everytime we code something, I think containers are .

I subscribe to this view for the next few years:

Serverless + edge computing is going to be that abstraction for most apps, and in some cases it already is.

We're just at the beginning, that's all. We tend to equate serverless to function as a service, but it's so much more. Google has been offering serverless computing since 2008 with AppEngine, Heroku since 2007.

People use higher level languages all the time because of how more productive they are, even at the expense of "speed". Such productivity comes from abstraction among other things.

Don't know how big your organization is but this is a good article about pros and cons of serverless for startups: The business case for serverless.

ps. serverless is hyped as well :D

 

I still haven't learnt using gdb to debug if necessary. And when you work with legacy code with almost zero test coverage, it would be necessary...

 

Might not be directly related to coding, but I spend way to much time on vim colors.

 
  • I am not very good at estimating.
  • I tend to look at too much best practices, which gets me confused sometimes.
 

That I treat the IDE code-checker like most people treat spell check.

"Get your stupid squiggly red line out of my face! I know my code better than you!!"

But here's the thing, I don't know my code better than "you"...

Classic DEV Post from Jul 30

What's your favorite question to be asked?

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.