Daniel Dunn's Personal Site!

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== What they don't teach you on coding blogs ======

Your job is not to write code.  Nobody will hire you because their company discovered a huge market for lines of code. Almost nobody will download an app and say "Wow, what great code!!!".

If it doesn't work in the real world, and doesn't meet requirements, it's not good code, no matter how many WorseIsBetter excuses you make. Once you actually learn to respect end-users, it gets a lot easier.

Even buggy code with a good UI and error handling can be better than clean code that expects to live in a perfect world. I 100% will not hesitate to increase software complexity if that's what it takes to handle user errors and unreliable networks.   And I don't even care if a few bugs slip in as a result, as long as the whole system, taking into account all the external issues, gets more reliable.



And then the next level after that, is that clever code is trash code.  Does your use of Tiermann's First order Polymeric Transform(Not a real thing) make anything faster?  Will it  help me port this later?  Does it enable some cool new feature?  Does it reduce bugs?

If not, I don't care.   If you've tweaked and tuned and debugged and got everything to be just perfect, down to ten lines with a recursive higher order function, I literally will not care.

If you did it at home and blogged about it, I would think it was cool(As long as you didn't pretend that kind of thing is going to carry over to real life projects), but if I have to deal with it, I'll be annoyed I had to wait for you to write it, then annoyed that I had to read it.




You probably can't do better than a standard library. And if you can, you probably don't have time.  And if you do, you'll still need to justify that it had real benefits, because, as previously mentioned, it's not about code, and the community behind the standards is worth more than a slight bit of extra code quality, unless you can show real benefit.

Even copy and pasting saves time, and most of the time, the thing you're copying is very obvious.  Why bother reinventing? If this is an educational drill... When do the real projects start?


And maybe most importantly, nobody is going to use your amazing new framework unless you can seriously support it.  Maybe it's better than anything that came before, and will inspire a few.   But a lot of the people who would care, have their *own* amazing new framework.  And the practically minded won't look beyond the word "new", and will read it as "untested trash full of undocumented behavior that the author learned to work around isn't going to fix".

In interpersonal growth there's the idea of "listening to understand" vs "listening to reply".  Be honest with yourself about what others are really going to be doing.  You can fart the world's best fart, but the other fartists will prefer their own.


Look at things from a high level.  What do the trusted solutions that people love do?  What are people complaining about? Do the successful projects use original code or libraries? What kinds of changes are likely to create a nightmare of bugs?

Unless you're formally proving things, the high level decisions of coding aren't math or science, they're art.  Theory and blog posts don't replace understanding the application and providing value of users.


Which reminds me, programming blogs all say the same 10 oversimplified things, usually about the virtues of oversimplifying things.  If you're reading this, you should probably be reading about a quarter the amount of programming content you actually do.

Do you know how to program? Great. Keep doing that and you'll get better, till you decide to change careers.   

You don't need to sacrifice your whole life at a glowing rectangular pixel shrine, doing code katas all weekend.  You certainly don't need to do competitive coding. And if you do choose to do those, remember that your ultra clever one liners and obscure patterns are just one more nonstandard thing for the maintainers to learn.


And finally, if you gain enough respect that people care about your opinion, you almost certainly WILL have to defend the projects you work on from people who want to make the whole codebase their personal splashy fun times pool of Haskell and Lisp metaprogramming, microservices, and custom build tools, and they might not even know Haskell yet(!).  That someone might even be you, and that project might be a website about coin collecting.

Think really hard about what the actual benefits are.  Maybe there's something to gain by having everyone learn a new language on the clock.   Or maybe, this is a two-person job and you shouldn't make real paid projects into testing grounds, when they should be very simple and easy.

Don't invent more work just because you're bored.  Get the task done, and go learn Haskell on your own time, or suggest your boss set aside a few hours for everyone to learn whatever it is.  But make sure you never wind up with a project full of super cool tech that only one person understands, just because you couldn't say no.
Daniel Dunn's Personal Site!

Page Tools
