mudasobwa
Creator of Cure
mudasobwa
Creator of Cure
TBH, I would reject an offer myself, if it comes to “how many tools do you know”-like questions. I can solve problems, that’s why. If there is no tool to solve it on hand, I would do kinda research, and if it does not bring up anything satisfactory, I’ll create the tool myself. That’s it.
Even more, I can barely name three so-called “patterns,” let alone “tools,” and people knowing the name for each and every pattern in the universe, very rare were able to …ahem… apply any of it to the real world problems.
4
NobbZ
Why you get hired over someone else, does not really depend on your skills alone, there is this thing called “company culture”, which might be an explicitly stated and lived thing, or just some thing that evolved implicitely.
So you have to be a fit for that culture, and that culture has to be a fit for you. I don’t give a **** for getting 20 or 30% more when I already realize during the process that the culture is not one of my taste.
And of course, it always depends on whoever holds the interview… There is something involved we call “Nasenfaktor” in Germany, which basically describes the massive influence of the first impression usually based on how you look or what you wear.
For me, if the only concern was getting hired, I’d do JS/TS, Java, or PHP. But my concern is having some fun learning and coding.
5
mudasobwa
Creator of Cure
D4no0
I used to think a few years ago, too, that keeping up with tooling from elixir ecosystem (and not only) is important and should be a focus.
These days as I shift more to trying to break free from these glorified factory worker jobs, I understand that tooling is just a small part of the problem and understanding how to solve the problem correctly amounts to actual drastic improvements in efficiency.
In some cases it is very true that finding the correct technology to solve the problem can make it much more manageable and this is where the community comes in. Almost all of us solve problems in different domains and are acquainted with the tools and their state. For example I worked mainly with small companies that always needed web interfaces, and the release of liveview couldn’t be more perfect.
Now I not only know how to use liveview effectively, but I can consult others whether it would make sense for them to adopt it or go with another technology and this IMO is where the true value lies. Knowing who to reach to ask for advice is the key thing that is much better than trying to process all of that information on your own.
These days the only technology news I read is from lwn.net and elixirforum (even though the forum is more of a place I value for conversations like this than hard technical specifics) and occasional random sources from time to time for my personal interest in technology. I think that following feeds and other similar things is the easiest way to kill your productivity and focus, and waste your time.
2
Fl4m3Ph03n1x
Thank you all for the wonderful replies!
I cant possibly refer to all of them, so I have picked some that lead me to more questions.
I believe both of these are related.
I believe that the more tools you know, the easier it is for you to add business value because the chances of using the right tool for the job increase.
I will give an example:
- Use Redis with a cluster of Elixir apps to serve as a global caching mechanism
- Use Elixir ecosystem with cachex (and perhaps nebulex, although not required) to achieve a distributed global caching mechanism
Both options aim at achieving the same: a global caching mechanism.
-
Option 1, requires you to understand elixir, redis, and the edge cases of how redis behaves under heavy load and failure. It also requires you to know how to use redis as a persistent storage system.
-
Option 2 relies solely on Elixir’s knowledge. You do need to learn how to use cachex, and that may not be trivial.
At the end of the day, option 2 requires less tools to achieve the same result. But I, don’t know how to use cachex, only redis. Should I invest my next weeks learning option 2, or stick with what I already know?
I believe the person going for option 2 would have an advantage on me as they would potentially be able to achieve the same end goal with less tooling. As a result, ironically, learning more tooling is required in order to use less tooling.
Let me know if I am missing something.
So, my recent dive into a more transversal topic, DDD is something you see a more worth while investment, right?
I do struggle with this. Usually my job is a fundamental part of my life, an anchor if you will. Perhaps this is why our vision is so different.
I usually lean on the side of “I will adapt as best as I can to whatever culture the company has”. Sometimes it works, other times it leaves you damaged and broken beyond recovery.
At the end of the day, and because I have a family to keep, 30% increase in compensation does mean a considerable change for my family.
By reading more I am starting to see a pattern in here where people are not really worried about being replaced or about job security. It feels like some members here have a very different mind set from what I experience.
It looks like you deal with my anxiety in a different way, becoming a generalist problem solver.
The problem I have with this approach is that every time a new problem arises (and in this area we are blessed with never ending problems to solve), you need to learn everything from scratch, using the new tools and systems. This is fine when you are younger and have more energy/time, but as the clock keeps on ticking, the resources to always go from 0 to hero become less and less.
How do you deal with this?
A fair point.
0
c4710n
I believe it is because we have a problem that we seek solutions, and then look for available tools, instead of matching tools to problems.
Take your example, for instance:
- “Oh, the db query is very slow” - the problem
- “We have no time to improve the performance of query, so we add a cache for the query result” - a possible solution
- “Are there any existing tools available? ” - try to discover available tools.
- First, people will think of Redis. Then, Let’s search “Elixir Redis”. We’ll find whatyouhide/redis. If you or your team are satisfied with this tool, you can use it directly. After all, using fancy technology won’t increase your business value.
- But, if you or your team heard that Elixir and Erlang are powerful, so perhaps you may think that you don’t need to use Redis. Let’s search “Elixir cache”. We’ll find whitfin/cachex.
You can see, all of this doesn’t require us to follow trends or keep up with news. Instead, we start from the problem and look for possible solutions through through multiple channels:
- search engine
- forums
- friends
- …
This is not a simple decision. You need to consider:
- your or your team’s preferences
- the current state of your infrastructure
- your personal enthusiasm (For me, I wanna simpler stack, so I might choose to learn cachex)
- …
You can think of it this way: “I need to solve a problem, and I want to solve it elegantly with as few tools as possible. First, I need to do some research to understand what solutions others are using and what their pros and cons are. And, then, choose the one that best matches my problem and has the lowest cost.”
Did you notice the main difference? Everything starts from the problem, not from the tools.
If you still feel the need to master or learn more tools, you can settle for just knowing more tools, instead of wasting time on learning technologies you might never use.
What is the meaning of knowing more tools? You only need to know a one-sentence description of every tool, and create a map for yourself:
* cache
- cachex - an extremely fast in-memory key/value store with support for many useful features, without using Redis
- ...
* params validation
- ecto changset - ...
- params - parameter structure validation and casting with Ecto.Schema.
You don’t have to master it or learn it, just know what it is. That’s enough. When you really need it, it’s not too late to learn.
3
sodapopcan
As @dimitarvp said, this is what we signed up for. There’s no real getting around it, but it can be mitigated, and I’ve been doing so my whole career. I’ve used the same text editor for well over a decade, the same OS, and generally the same tech. One of the top reasons I landed on Elixir is due to its stability and its “it’s possible we’ll never see a 2.0” mindset. I also rejected the utility of things like Angular and React for business applications and have largely managed to avoid them (except for about 2.5 years).
Of course, you can still be fine being stubborn and sticking with literally the same tech and never adapting, though you will probably eventually have to become a manager. I knew a guy who was a terrible programmer in terms of code quality though had really good product sense and made apps people wanted to use. He only knew AS3 and refused to learn anything else. He now has a high up position at a large cinema company as they still had the need for AS3 in 2015 when they hired him.
This is really it.
The point is that it’s how people feel about you in the interview. Well, it is about how you feel about each other, but it depends on who is being pickier. As someone who has done a lot of interviewing, if the candidate shows they have basic programming skills then my decision is going to be based off of their willingness to learn and adapt and how I feel they will fit in at the company. I actually wish companies were allowed to be more upfront about this—for me it would sting much less to learn I didn’t get a job because they didn’t like me as a person rather than that they thought I was a bad programmer 
3
slouchpie
I telepathically siphon knowledge from the rest of you (via your astral bodies while you are sleeping).
6
