Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I think there's a fundamental difference between work and private.
Work curiosity is in my opinion a must - and I had endless discussion about it.
At least if they're working in IT.
The field is constantly changing and without curiosity people just do the same shit they've done before without exploring any (better) other solution to their problem.
Plus the cost to give someone e.g. first level support just because they don't want to learn stuff is really high.
From a manager perspective, this cost is a really big problem from my experience - cause most of the time, the person giving first level support is another dev or someone with an equally high pay grade.
Which means that two or more devs are wasting precious time - because one simple refuses to educate himself.
When someone does not have any interest to educate themselves privately, I don't care - but in a work environment, these costs could easily amount to e.g. the necessary pay for another dev / better hardware / etc. -
Assumptions are a bitch in general.
Anyway, I have been on both sides as a "technician". Our minds usually look for patterns and familiarity. So if a certain tool/lib/plugin has been used in a project and we need similar functionality in another (part of the) project, I will probably copy-paste it just to make it work. This can be seen in work/tools where you're NOT interested in or where work is repetitive (boring). Patterns bring more patterns. -
My personal opinion on this is that people that work with the software use it as a tool and ofc wanf it to work as simole as possible. If I want to build a table I don't want to configure my saw, I want to focus on how my table's gonna look like. The tool should save time and reduce stress. When we develop software we also don't care about the inner workings of our text editor or IDE. We want it configured as simply and quickly as possible to our needs and then focus on the software we write.
I think thats a viewpoint that we often forget.
They taught you a lot..🙋🙋
Microsoft tech summit... Doesn't need a comment
Assumptions are a terrible idea, yet I find myself making them all the time about other people. I am finding the very sobering reality about people who use technology vs people who create technology. The users have zero intellectual interest in how the technology accomplishes a task. While the creators get absorbed into the details and often relish in being able to maximize capability.
A point of frustration for me is users who are in a semi technical field yet take zero time to learn how to configure a piece of tech. They get a plug and play attitude and seek in panic when things don't work. The work is semi technical because they need to understand some of the fundamental physics involved to assess things using instrumentation. Yet when asked about a system they actively modify as to how it is normally setup they are clueless. Me, who helps write the software to control these devices, is stumped that they have zero interest (or capacity?) to understand how the system is normally configured. This is not the first time I have made assumption about what they know in technical contexts. I have run into this before with managers, but not with technicians.
How do you manage your expectations with people who won't invest any time into how their equipment actually works? How does someone operate that way to begin with? Where is their curiosity about how things work?
On the flip side, I swear at my fucking phone because I don't care how it works, but I just want it to stop doing everything besides being a phone... Fuck you, we are not the same, I think...
question
knuckle draggers
tech