What’s a habit or behavior you probably wouldn’t put on your resumé?
For further actions, you may consider blocking this person and/or reporting abuse
What’s a habit or behavior you probably wouldn’t put on your resumé?
For further actions, you may consider blocking this person and/or reporting abuse
OpenSource -
Serhii Babich -
Thomas Bradley -
Luciano Jung -
Oldest comments (101)
I’ll start:
Things I continue to work on, but not my best coding qualities. 😋
git rebase
as often as I shouldI’m a safe and cautious git user and I tend not to mess things up too badly. But I rarely have a good idea of how to get out of a mess without too much collateral damage.
I sometimes have tendencies to push to origin/master...which is, sadly, locked.... but by me, haha, so when I'm on the roll, nothing will stop me!
I'm with you linters. I tend to get annoyed by them. They often lead devs to focus on really pedantic problems. With linter indoctrination, you'll be looking at another dev's code and think "Oh they used an if statement to assign a nullable value instead of a ternary statement. They should fix that." Instead of "the overall maintainability of this code looks good."
I spend way too much time thinking of every edge case and how things will scale. That tends to slow down my coding tasks. And I have a lot of coding work on my plate.
Swap #2 for a language everyone likes to hate and I'm right with you. :)
COBOL?
If you hate Perl too then we should create a Foundation or something
I
console.log()
things more often than setting a breakpoint and hitting the debugger. Working on it.There's nothing wrong with println debugging! While breakpoint debuggers are a great tool, it is really hard to use them well in async code, which is where good logging is an absolute must! And sometimes, it's just faster and easier to print logs instead of stepping through line-by-line
the old reliable!
I Google almost everything because I don't remember the APIs, just that there is a way to do it.
Hah. Everybody does this, so much so that Google actually put in a recruitment ad for people searching certain programming related queries.
I'm with you on this one...
I've been working in a particular platform so long that I've recently began to wonder if I actually still know how to code or whether I've just become particularly skilled at rearranging various snippets of code.
Whatever it is - the one thing I know for sure - I'm reasonably gifted at articulating my problem in a way that I can (usually) find the StackOverflow answer to solve the problem
Seems to work out for many React ⚛ devs.
And that's what's recommended by Dan Abramov 😛
click on the link in Dan's tweet
That's why I have like a ton of docsets in Zeal
I rely on my IDE autocomplete so much I sometimes forget the standard library
Same! Google driven development
That's not per se bad. Knowing a solution exists and looking it up is way better than solving a problem you shoudn't have to
I'm pretty bad at asking questions. I'm definitely more comfortable digging through the mire of docs and source code than reaching out for help.
I used to be reaaaaallly bad this way. I’ve become more comfortable asking questions over time.
I still feel like my dev lingo knowledge is 2 years behind my actual knowledge and every time I am talking to someone I will never stop and ask what a word or abbreviation means. Instead I make a mental note, then after the conversation sit on google for 5 min figuring out what they just said and having ah-ha moments 😂
I do this. I worry about whether not knowing an acronym will make me look stupid.
I think "I could ask but I need to do this by myself" and then I waste hours searching. I don't want to bother others when they are busy
I'm scared of contributing. I'm afraid of finding out that I'm incompetent so when I challenge myself to find a project to contribute to, I end up scrolling on github until I run away. Dare try to talk me into any, I have more excuses than gifs in @ben 's portfolio 🤣
That was me for years, and now all my code is out there for the world to see. 😳
This was totally me a year ago then I found some things I REALLY needed fixed in a few gems and that is what pushed me to finally do it. That first PR was SO stressful but I did survive and it has gotten a lot easier 😊
Stop scrolling, contribute to dev.to! :-)
Do I need ruby to do so? I'd need to brush up on it a lot
The backend is in Ruby and Rails, the frontend is in HTML/CSS/JavaScript/React/Preact. The documentation is in English :P
You could submitting a bug report, submit a feature requests or reading over other pull requests to make sure they make sense and that still counts as contributing 🙂
I think with also this approach, I'll understand the 'why' . The 'how' is always the easiest
Happens with me a lot 😅😅
I don't understand functional programming.
I've been preaching functional programming for several years now, and I still don't even grasp all the concepts.
FP is hard!
I think if you go down the rabbit hole of CSP, monads, combinators than it really gets trick but the basics are simpler than some people make them to.
You don't need to have a "pure" functional language to take advantage of it.
Use functions without side effects, pass functions as arguments (you do this all the time if you work with JavaScript and callbacks), envision your code as a series of composable operations instead of telling something to change state.
It's perfectly fine if you don't do it all time, or ever :D
Chances are you're already doing without knowing it.
We (FP programmers) are great at making it not very understandable.
When someone asks me for help and I can't figure it out I use stackoverflow solutions
I've recently been working on this, but I too often take a get-in/get-out approach and forget to take a step back and consider the big picture.
Up until recently I didn't understand Test Driven Development at all and thought it was crazy. I'm still not fond of unit tests where I'm trying to fix a bug, and I have to figure out why the unit test is now breaking.
git commit --amend
. Less so now that GitHub shows force pushes. 😬No shame in
--amend
ing; also no shame in re-writting the history...just don't do it after pushing to a remote :fire_eyes:I have no idea what dependency injection is and why I need to know about it.
That's because many people who explain it are clueless as well and tell you some overcomplicated bullshit. Actually it's quite a simple thing, not much more than programming against interfaces instead of implementations. You should know about it because it simplifies unit testing. Once you got this, you will find other benefits.
I like how IoC takes away the responsibility of layers to know about the creation of other layers (or their scope). Via DI, my controller can have a repository object injected by the IoC container, and the controller doesn't have to manage the lifecycle of the repository object.
Also, in unit tests, the repository object is easier to mock because I don't have my controller creating the instance in a constructor or something my test doesn't have access to.
DI can make things harder to read if the framework is limited to injecting interfaces and the interfaces have several implementations.
If you understand the difference between composition and inheritance in OOP you understand dependency injection, the rest is lingo to make it sound more complicated than it actually is
I never practice TDD, I always write tests after I write the code. It just seems faster and easier 🤷
I also am not great with linux, I have to google simple command line commands all the time. I'm working on it though!!!
TDD is incredibly unintuitive and the majority of developers do not use it.
It is a great skill to eventually take to IMO. But there’s no rush. It’s someyhing worth casually nibbling on until you find places it really clicks.
I do hybrid testing, mostly after, sometimes TDD
I used to preach it but like all methodologies, it doesn't work all the time and requires a lot of discipline.
It's probably counter intuitive but I did a lot more TDD when I was a total noob, now I trust myself more. I have a mental map of most of the tests I have to write for the feature I have. If they are too many I write them in the ticket or a text file or whatever.
I think TDD shines with refactoring, more than for new features
TDD only comes natural to me when it actually improves my productivity, which happens around 10% of the time.
TDD is helpful when you are writing pure functions which the result is predictable. For example, if you are writing a function that uses Regex to transform a string, it is much easier to TDD it until it works than running your entire system on every change until it works.
I usually write my code first, add unit tests for new features/bug fixes, and then rely on my code coverage tool to tell me where I need to have more tests.
console.log()
stuff.You know, none of that was too bad. I feel like less of an imposter writing it out. 😊
Regarding the terminal... get
fzf
and integrate it into your shell. Then you can type CTRL-R and fuzzy search your history! Super great.Run
Then
The Git built in CLI visualizer for git history. :D
Some comments may only be visible to logged-in visitors. Sign in to view all comments.