9 changed files with 109 additions and 5 deletions
@ -0,0 +1,29 @@ |
|||||||
|
+++ |
||||||
|
title = "Things I Learnt The Hard Way - Don't Defend Bad Code" |
||||||
|
date = 2019-07-31 |
||||||
|
|
||||||
|
[taxonomies] |
||||||
|
tags = ["en-au", "books", "things i learnt", "personal", "bad code", "defend"] |
||||||
|
+++ |
||||||
|
|
||||||
|
Bad code exists everywhere. You shouldn't defend it, even if it is your own |
||||||
|
code. |
||||||
|
|
||||||
|
<!-- more --> |
||||||
|
|
||||||
|
Bad code isn't bad on purpose. It sadly happens. But because it is bad, you |
||||||
|
shouldn't defend it. |
||||||
|
|
||||||
|
For example, an application does whatever you need. But it crashes from time |
||||||
|
to time. Software shouldn't crash and you shouldn't defend it just because it |
||||||
|
does whatever you need. |
||||||
|
|
||||||
|
Your internal application works on a single browser. That's bad. "But maybe |
||||||
|
the other devs thought it wouldn't be worth working on all browsers". No. It |
||||||
|
is _bad_. You shouldn't defend the other devs because they decided to focus on |
||||||
|
a single browser due whatever problems they were facing. Sure it wasn't nice |
||||||
|
that they had to do this trade-off, but it is still _bad_ software. |
||||||
|
|
||||||
|
If we keep defending this kind of software, we will still get bad software. |
||||||
|
|
||||||
|
{{ chapters(prev_chapter_link="/books/things-i-learnt/own-your-shit", prev_chapter_title="Own Your Shit") }} |
||||||
@ -0,0 +1,42 @@ |
|||||||
|
+++ |
||||||
|
title = "Things I Learnt The Hard Way - Global Changes Must Be Discussed With The Whole Team First" |
||||||
|
date = 2019-07-31 |
||||||
|
|
||||||
|
[taxonomies] |
||||||
|
tags = ["en-au", "books", "things i learnt", "team", "changes"] |
||||||
|
+++ |
||||||
|
|
||||||
|
So you got tired of bad tests and decided it is a good idea to add some [fuzz |
||||||
|
testing](https://en.wikipedia.org/wiki/Fuzzing) tool. Before you do add it in |
||||||
|
the main branch, you _have_ to discuss it with your team. |
||||||
|
|
||||||
|
<!-- more --> |
||||||
|
|
||||||
|
It's mind-bogging that some people think something it's so good that they |
||||||
|
don't need to discuss with the whole team about it; they simply do. They don't |
||||||
|
seem to care that people have their workflows and changing something would |
||||||
|
break them. But hey, I've seen it so many times it is not even fun. |
||||||
|
|
||||||
|
And let me clear here: You need to discuss it with the _whole_ team, not just |
||||||
|
some of it (excluding people on vacations, 'cause you don't want to call them |
||||||
|
just to tell them something will change). Worse: Don't discuss only with those |
||||||
|
that will agree with you; you may not have seen all the problems those changes |
||||||
|
will inflict on the other devs workflows but, by bringing that with those that |
||||||
|
may not agree with you, you may gain some more insights on what could go |
||||||
|
wrong. |
||||||
|
|
||||||
|
Also, focus on what would be the gains and the loses. "We'll get better tests, |
||||||
|
but you'll have to take a bit more care on the way you write tests" is a good |
||||||
|
explanation, specially if you show the changes people will have to do in |
||||||
|
future tests. Also also, notice that I said _future_ tests: if you want to |
||||||
|
implement something new, you _must_ be sure it won't require everyone getting |
||||||
|
out of their way to make your idea work -- don't make people rewrite tests |
||||||
|
'cause they will break; don't make the other devs reformat their code 'cause |
||||||
|
you decided, alone, to add a linter to your CI with your own rules; don't make |
||||||
|
people worry about unwritten tests 'cause you decided it would be a good idea |
||||||
|
to add a code formatting tool and that would make your coverage tool think |
||||||
|
they are changing some unrelated piece of code that wasn't untested before. |
||||||
|
|
||||||
|
Don't be a jerk thinking you know more than your whole team. |
||||||
|
|
||||||
|
{{ chapters(prev_chapter_link="/books/things-i-learnt/hero-projects", prev_chapter_title="Global Changes Must Be Discussed With The Whole Team First", next_chapter_link="/books/things-i-learnt/specialists", next_chapter_title="Companies Look For Specialists But Keep Generalists Longer") }} |
||||||
@ -0,0 +1,30 @@ |
|||||||
|
+++ |
||||||
|
title = "Things I Learnt The Hard Way - Be Transparent With The User" |
||||||
|
date = 2019-07-31 |
||||||
|
|
||||||
|
[taxonomies] |
||||||
|
tags = ["en-au", "books", "things i learnt", "ux", "ui"] |
||||||
|
+++ |
||||||
|
|
||||||
|
Since we are talking about [logging](/books/things-i-learnt/log-events), |
||||||
|
another thing you must do is to be transparent with the user in your user |
||||||
|
interface. |
||||||
|
|
||||||
|
<!-- more --> |
||||||
|
|
||||||
|
And by "be transparent", I meant that your website/mobile app needs to point |
||||||
|
out to the user that the webserver is down instead of saying to the user to |
||||||
|
check their internet connection; your application _is_ getting something from |
||||||
|
the webserver, so you _can_ say "Oops, something wrong on our side". |
||||||
|
|
||||||
|
Another example: If you need to check a bunch of data before saying "It's |
||||||
|
done", add a counter to show the user that the application is doing something. |
||||||
|
[Joplin](https://joplinapp.org/), when syncing data with a webdav server, |
||||||
|
needs to check a bunch of files; one version would simply sit still with a |
||||||
|
spinner on "Syncing" and nothing more; when they added a counter, I could |
||||||
|
easily see that there was something going on. |
||||||
|
|
||||||
|
Those small details, for as bad as they may make you look, will win points |
||||||
|
with the user in the long run. |
||||||
|
|
||||||
|
{{ chapters(prev_chapter_link="/books/things-i-learnt/log-events", prev_chapter_title="Logs Are For Events, Not User Interface", next_chapter_link="/books/things-i-learnt/add-then-remove", next_chapter_title="One Version To Add, One Version To Remove") }} |
||||||
Loading…
Reference in new issue