11 changed files with 147 additions and 6 deletions
@ -0,0 +1,43 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Companies Look For Specialists But Keep Generalists Longer" |
||||
date = 2019-07-17 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "jobs", "specialists", "generalists"] |
||||
+++ |
||||
|
||||
If you know a lot about one single language, it may make it easier to get a |
||||
job, but in the long run, language usage dies or loses its charms and you'll |
||||
need to find something else. Knowing a bit about a lot of other languages |
||||
helps in the long run, not to mention that may help you think of better |
||||
solutions. |
||||
|
||||
<!-- more --> |
||||
|
||||
Even if you're in a shop that is mainly in one single language, that's no |
||||
excuse to not check other languages. But, then again, learning languages that |
||||
are just small changes on the current language would not help you either. |
||||
|
||||
Alan Perlis, author of the ALGOL language, has one excellent phrase: "A |
||||
language that doesn't affect the way you think about programming, is not worth |
||||
knowing." |
||||
|
||||
I still maintain one single rule for programming languages: The language I use |
||||
at work must not be the same language I use outside it[^1]. That simple rule |
||||
made sure I was always learning something new. |
||||
|
||||
Learning a new language can also help you understand things in some language |
||||
you used before: Rust help me understand how generics works in Java; seeing |
||||
how to do dependency injection in C++ help me understand how Spring does it in |
||||
Java. |
||||
|
||||
On top of that, because I was always learning something new, moving between |
||||
projects was something that happened a lot. At one point, I was hired to work |
||||
with Python, but the contract was taking too long to be signed, and my manager |
||||
asked if I could help some other team with their iOS application. Because I |
||||
did learn a bit about Objective-C, surely I could help. Later, another project |
||||
in C show up and guess who also knew C? |
||||
|
||||
[^1]: ... which led me into some sad times when I was working with Python. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/google-code-style", prev_chapter_title="... Unless That Code Style Is The Google Code Style", next_chapter_link="/books/things-i-learnt/stupid-bugs-list", next_chapter_title="Keep A List of Stupid Bugs That Took More Than 1 Hour To Solve") }} |
||||
@ -0,0 +1,24 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Keep A List of Stupid Bugs That Took More Than 1 Hour To Solve" |
||||
date = 2019-07-17 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "lists", "stupid bugs"] |
||||
+++ |
||||
|
||||
If it took you more than one hour for you to figure out what went wrong, it is |
||||
a good idea to put it on list, 'cause these things have the tendency to appear |
||||
again. |
||||
|
||||
<!-- more --> |
||||
|
||||
I must admit that this is one thing that I should be doing, but I keep |
||||
forgetting. The worst part: It usually takes me about an hour to figure out |
||||
what went wrong, only to realize by the solution that I had the same problem |
||||
(with the same solution) before and it took me about one hour to figure out |
||||
what went wrong. |
||||
|
||||
If I just had a list of stupid bugs that took me about 1 hour or more to |
||||
solve, I wouldn't be stuck for another hour figuring out what went wrong. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/specialists", prev_chapter_title="Companies Look For Specialists But Keep Generalists Longer") }} |
||||
@ -0,0 +1,29 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Units Makes Things Clear" |
||||
date = 2019-07-17 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "units", "explicit"] |
||||
+++ |
||||
|
||||
You know what's one of the worst function names ever? `sleep()`. |
||||
|
||||
Sleep for how long? It is seconds or milliseconds? |
||||
|
||||
<!-- more --> |
||||
|
||||
Now let me ask you this: Would it clearer if the function was called |
||||
`sleepForMs()`? Would you understand that the function would make the |
||||
application sleep for a number of milliseconds? |
||||
|
||||
What about `sleepForSecs()`? Do you understand that this will force your |
||||
application to sleep for a number of seconds? |
||||
|
||||
What if, instead of using the function name, you could use `sleep("10s")`? Does |
||||
it make clear that you want it to sleep for 10 seconds? |
||||
|
||||
That's why adding units to the function or parameters make sense. It removes |
||||
the ambiguity of what it means and doesn't rely on some specialized IDE/Editor |
||||
that display the parameter names. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/optimization", prev_chapter_title="Optimization Is For Compilers", next_chapter_link="/books/things-i-learnt/config-file", next_chapter_title="The Config File Is Friend") }} |
||||
@ -0,0 +1,35 @@
|
||||
+++ |
||||
title = "Things I Learnt The Hard Way - Think About The Users" |
||||
date = 2019-07-17 |
||||
|
||||
[taxonomies] |
||||
tags = ["en-au", "books", "things i learnt", "privacy"] |
||||
+++ |
||||
|
||||
Think how the data you're collecting from your users will be used -- this is |
||||
more prevalent on these days, where "privacy" is a premium. |
||||
|
||||
<!-- more --> |
||||
|
||||
I once had a discussion with a CTO about collecting the user IMEI on our |
||||
mobile app. Basically, there was no use case for capturing that information |
||||
yet but, as he put at the time, "We may want to know if one user uses two |
||||
phones, or if two users use the same phone". I raised the fact that we didn't |
||||
need this information and, besides that, it felt like we were invading the |
||||
users privacy. He still decided to go ahead. My answer: "I'll do it, but I |
||||
want to point that I'm not happy with it." |
||||
|
||||
In the end, the store blocked the app... because we were capturing the IMEI. |
||||
|
||||
But there are cases and cases. If you really _really_ need to capture user |
||||
information, be sure to protect it against unauthorized use, be it by external |
||||
forces (someone found a way to attack your data) or internal (some disgruntled |
||||
colleague decided to take the data from your users with them). |
||||
|
||||
And be sure, there _will_ be a leak at some point, it's just a matter of time. |
||||
If you can, the best way to protect your users data is to never capture it. |
||||
When a flaw on your system is found or when some colleague leaves the company |
||||
in bad terms, there will be no data to expose to the world, anyway. You can't |
||||
be more secure than this. |
||||
|
||||
{{ chapters(prev_chapter_link="/books/things-i-learnt/debuggers", prev_chapter_title="Debuggers Are Overrated", next_chapter_link="/books/things-i-learnt/integration-tests", next_chapter_title="Unit Tests Are Good, Integration Tests Are Gooder") }} |
||||
Loading…
Reference in new issue