Julio Biason
5 years ago
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