To many jobsdescriptions are over complicated just to sound fancy. Let's have a little fun here. Explain in the shortest and simplest way possible what 90% of your day to day job is. I'll start:
Directing people to read the documentation.
For further actions, you may consider blocking this person and/or reporting abuse
Sloan the DEV Moderator -
Noishorgo Broto -
Nik L. -
dev.to staff -
Once suspended, david_j_eddy will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, david_j_eddy will be able to comment and publish posts again.
Once unpublished, all posts by david_j_eddy will become hidden and only accessible to themselves.
If david_j_eddy is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to David J Eddy.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community safe. Here is what you can do to flag david_j_eddy:
Unflagging david_j_eddy will restore default visibility to their posts.
Top comments (37)
Looking at the requirements of a project, then looking at the code, then... (╯°□°）╯︵ ┻━┻
In all seriousness though its taking requirements and implementing them. Sometimes its in very old bad code, some ok code, and sometimes some really good code. The hard part is understanding the big picture when there are thousands of tables, separate systems that need to talk to each other and with almost none of it documented.
THIS. Exactly my job real description.
Fiddling...
I’m always fiddling with something. Code, design, copy, whatever. I’m a fiddler.
I'm assuming you use this site a lot then jsfiddle.net :'D
Knowing and telling everyone what everyone else is doing.
Okay, I do a lot of translating between coder-speak and human too, and help everyone with everything, both coding-related and other stuff. Keeps everyone happy if they only have to concentrate on their own job. And happy means efficient.
This, pretty much, plus a bit of talking about security stuff so we can all be equally paranoid, and have less 'bloody infosec'/'bloody idiots' in relationships!
#ParanoiaEquality
"How do I print?"
uuuhhhggggg, not again!?
I get called about the copier pretty frequently too, though mostly by the same person -- and usually when convenience is low.
One of my favorites is those that try to fax. They type in the phone number, put in the paper... But then never hit "start fax", and get confused when it doesn't work.
I can't say I've seen that where I work. So far, everyone I've worked with here at least knows there's an extra step to send.
I know that feel bro 👊
Communicating: teaching, learning, planning, aligning, reporting etc. 80% out loud, 20% written. Notably, not a ton of documentation.
Even when I'm hands on keyboard writing code it's still paired programming.
Honestly 90 % of my job is refactoring legacy code to the point in which it is usable & wondering if my client will pay me for it.
"fixing the prev. persons leftovers"
This.
Making things work, be it code, managing people, new hires, hardware issues and so on. There's no dull day from that point of view, there's always a 'fire' to extinguish somewhere.
90% of my job is keeping the lights on.
Avoiding meetings.
In job test: make a funcionar to calculate Fibonacci and draw the LINE with canvas/react/graphql/gulp
In job day: padding-top: 30px;
Review server-sided architecture - cry a bit about non-automated things - automate it - straightening it on each node - smile.
... thinking about whether you really need to implement it and if so, whether there is a better solution.
Asking "but what are you trying to achieve?"
Most of the requests that come my way say "I need this dataset, please provide it".
90% of the time there is a better dataset the analyst isn't aware of or some aggregating that I can do upstream that will get rid of a lot of the heavy lifting the analyst has signed themselves up for.
It's a nice feeling to be able to add value and not just be a 'data donkey', but I find myself asking "but what are you trying to achieve?" over and over and over.
Android development: write Kotlin code that fetches data from internet, display it in a list, and open a detailed view when you click on an item.
Figuring out actual acceptance criteria (since requirements are often too vague) by asking TPMs, architects, discussing AC of dependant teams, etc.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.