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
Dan Abramov
@dan_abramov
Okay, I give in. I wrote a guide on the most scalable file structure for React projects. I’m using it every day. Best part: it works for Vue projects too. Hope it’s helpful! ✨ react-file-structure.surge.sh
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
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 🤣
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 😊
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 🙂
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
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 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
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.
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.
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 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.
I'm a web developer using Laravel (PHP) and Vue.js. From Girona, Catalonia.
I'm always asking `how does this work?`
I'm always saying `never stop learning.`
I joined this year's Advent of Code but it's being pretty hard for me since day 3. I'm very good making websites, CMS, API's, objects/models, tests, all that stuff... But I suck at simple math operations or simple problems without objects 😭
I’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'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'm a full stack web developer who has been freelancing for the last 20 years. I write about everything from development to production and also have video courses on my site!
A single 4,751 line PHP file with mixed PHP, MySQL, HTML, CSS and JS is currently running in production for the last 12ish years on a shared hosting service.
The thought of maintaining this app scares the shit out of me, but luckily it's been running smoothly all this time.
4 years as a web developer and I
-still hate JavaScript and all it's frameworks
-everyday I hear about machine learning, artificial intelligence, block chain and still don't know anything deep beyond the superficial
-yet to contribute to any open source because I still suck at coding
-still not used to tech jargon
-still watch video tutorials to learn sthg new quickly, then later dive into documentation much later
There is a finesse to finding the right the granularity. The first test you write could take 20 lines of logic to turn green. I've found most tutorials use too many tests and too fine a granularity.
100% branch and line coverage isn't useful and hampers productivity. Getting tests done as you code does not.
I have a habit of googling for someone I don't know how to do and finding my own blog posts because I learned it, did it, wrote about it, and completely forgot about the entire experience. This has happened on multiple occasions.
My dad first introduced me to programming by helping me make tic tac toe with Visual Basic in Excel. We never finished it, but I went back and did it with Javascript a while ago.
It is impossible in the 3x3 grid to win by setting the first marker, the opponent player can always force a draw - although in second position against an optimal player it is also impossible to win. So, your game might have won easily against opponents with a non-optimal strategy.
I am so bad at async programming. I'm reading through the You Don't Know JS book about it but I have to read every chapter two or three times to get a grip on the concepts.
I use console.log() all the time, I don't plan to stop, and I leave it in server side production code when I use firebase.
I think going out of the way to through a debugger is pretty much admitting you don't really know what you're doing and just need to official about it.
I admit I'm probably wrong about of all this, but throwing my variables into console.log({}) and converting them to an object with the vars name on the fly is just too addictive.
I agree somewhat. A year on a team that does TDD has taught me when and where it is a great tool. No tool is useful all the time and everywhere.
Productivity isn't just this sprint. It is the productivity of the next 10 years of maintaining code.
Testing is complex and it will take teams time to ramp up from "testing what they know how to test" to "testing where it is needed".
Enterprise rarely has top notch code quality. When the devs are a rotating cast of various experience testing TDD keeps the tests flowing. Testing keeps devs from quitting, users from bad experiences and, ultimately, costs down.
I've made it up as I went along. I really don't know much about formal CS (despite nearly 20 years of professional development experience) - I've never really studied it. I feel like a fraud most of the time.
Oh and on one job I lost the company $100k in my first week on the job.
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'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.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Well this one took off - I guess catharsis is a good thing, here's mine:
I'm addicted to the teletype-induced Unix shorthand, that is: rm vwls, and I get all OCD about my variable names being the same length to make the code look pretty at the expense of readability. Four character names (without vowels) seem to be my favourite.
Luckily my PoCs tend to get burned down by professionals before production!
I'll often get really excite about a new technology or language, seeing it's potential to help my career. Then I'll hit a roadblock early on and give up way too easily.
I start coding hoping that the solution comes to me as I go along. This leads to comment stubs everywhere of Just do this here without actually knowing how to do it. I usually just make an empty function with the return value I want in the meantime
Sometimes I overthink the smallest task, making myself slow. is this correct? Can I improve it? Is there any better way? Am I using the correct standard? it's updated? and I spend hours reading, searching.
When I code I try to finish a process without performing debugging and in the end perform tests "ohh run to the first time"
I try not to memorize things because I think they will change it later. So I'm dedicated to remembering how to search it in google. Too many frameworks.
I still depend on google and stackoverflow. And although I know English, I still look for words that I do not understand in Google translator.
More of an OPS confession, but I don't really like AWS. Sure, it's fine, but so much of it is overly complex and unnecessary for 90% of the folks/cases that want to use it.
I am a young Christian, filmmaker, entrepreneur, and developer who wants to glorify God in all I do. I'm a full-stack JavaScript developer who specializes in the backend.
While I've been pitching Docker to my boss every since cgroups were introduced (a long time before Docker), I still don't understand how I could use it in practice
I'm hoping I can skip Docker as much as possible altogether. Not that it isn't important but there's a lot of hype. We went from "maintain your own server" to push-to-deploy (AppEngine, Heroku, AWS Elastic Beanstalk) to installing sofware over and over inside containers, to me it feels like a step back in terms of abstraction.
We need to move forward again.
Docker and k8s can be building blocks for that "future" but the same way we don't need to re-code every abstracted layer our apps sit on everytime we code something, I think containers are .
I subscribe to this view for the next few years:
Simon Wardley #EEA
@swardley
X : What's going to happen in cloud in 2019? Me : Nothing special. 1) Enterprise data centres will continue to close. 2) Cloud will decentralise in terms of provision not power i.e. Amazon will "invade" more of those holdouts with AWS Outpost. 3) Serverless will rocket.
13:32 PM - 15 Dec 2018
64154
Serverless + edge computing is going to be that abstraction for most apps, and in some cases it already is.
We're just at the beginning, that's all. We tend to equate serverless to function as a service, but it's so much more. Google has been offering serverless computing since 2008 with AppEngine, Heroku since 2007.
People use higher level languages all the time because of how more productive they are, even at the expense of "speed". Such productivity comes from abstraction among other things.
Don't know how big your organization is but this is a good article about pros and cons of serverless for startups: The business case for serverless.
ps. serverless is hyped as well :D
Darren Shepherd
@ibuildthecloud
@rstephensme@monkchips oh man... "serverless" is just like "cloud" in the early days, impossible to determine proper uses or marketing BS. I'd say serverless is the answer to "you said containers would make things simple and it's still too damn hard." So whatever that answer is, that's serverless
I Google almost everything because I don't remember the APIs, just that there is a way to do it.
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
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
Same! Google driven development
Hah. Everybody does this, so much so that Google actually put in a recruitment ad for people searching certain programming related queries.
I rely on my IDE autocomplete so much I sometimes forget the standard library
That's why I have like a ton of docsets in Zeal
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 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
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 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.
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 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
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.
Half my commit messages are "git commit -m 'Doing stuff'" :D
git commit -m "random shit"git commit -m "i don't even know"git commit -m "stuff"I'm in the same boat.
Hahaha! So you've been doing just Frontend huh?
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.
console.log()stuff.You know, none of that was too bad. I feel like less of an imposter writing it out. 😊
Run
Then
The Git built in CLI visualizer for git history. :D
Regarding the terminal... get
fzfand integrate it into your shell. Then you can type CTRL-R and fuzzy search your history! Super great.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 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 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 do this. I worry about whether not knowing an acronym will make me look stupid.
I used to be reaaaaallly bad this way. I’ve become more comfortable asking questions over time.
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.
I joined this year's Advent of Code but it's being pretty hard for me since day 3. I'm very good making websites, CMS, API's, objects/models, tests, all that stuff... But I suck at simple math operations or simple problems without objects 😭
I’ll start:
Things I continue to work on, but not my best coding qualities. 😋
git rebaseas 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."
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
A single 4,751 line PHP file with mixed PHP, MySQL, HTML, CSS and JS is currently running in production for the last 12ish years on a shared hosting service.
The thought of maintaining this app scares the shit out of me, but luckily it's been running smoothly all this time.
I can't code unless my text editor has a blue background.
git commit --amend. Less so now that GitHub shows force pushes. 😬No shame in
--amending; also no shame in re-writting the history...just don't do it after pushing to a remote :fire_eyes:4 years as a web developer and I
-still hate JavaScript and all it's frameworks
-everyday I hear about machine learning, artificial intelligence, block chain and still don't know anything deep beyond the superficial
-yet to contribute to any open source because I still suck at coding
-still not used to tech jargon
-still watch video tutorials to learn sthg new quickly, then later dive into documentation much later
...got a lot to improve/change 😭
There is a finesse to finding the right the granularity. The first test you write could take 20 lines of logic to turn green. I've found most tutorials use too many tests and too fine a granularity.
100% branch and line coverage isn't useful and hampers productivity. Getting tests done as you code does not.
I have a habit of googling for someone I don't know how to do and finding my own blog posts because I learned it, did it, wrote about it, and completely forgot about the entire experience. This has happened on multiple occasions.
I do the same. I wrote a blog with some solved problems so I can have it at hand.
Even after closing in on 10 years of being a professional developer I'm too insecure to share anything substantial in this post.
I always think if I'm updated enough to share
My first real computer program was written in Basic on the C64; tic-tac-toe.
My dad first introduced me to programming by helping me make tic tac toe with Visual Basic in Excel. We never finished it, but I went back and did it with Javascript a while ago.
It is impossible in the 3x3 grid to win by setting the first marker, the opponent player can always force a draw - although in second position against an optimal player it is also impossible to win. So, your game might have won easily against opponents with a non-optimal strategy.
Very possible, I was 12 when I wrote it.
I spend too much time trying to guess what's wrong with my code instead of just debugging right away and realizing I flipped an if/else condition.
I am so bad at async programming. I'm reading through the You Don't Know JS book about it but I have to read every chapter two or three times to get a grip on the concepts.
Shameless plug:
Introducing the Async Debounce pattern
Rémy 🤖
I use console.log() all the time, I don't plan to stop, and I leave it in server side production code when I use firebase.
I think going out of the way to through a debugger is pretty much admitting you don't really know what you're doing and just need to official about it.
I admit I'm probably wrong about of all this, but throwing my variables into console.log({}) and converting them to an object with the vars name on the fly is just too addictive.
I agree somewhat. A year on a team that does TDD has taught me when and where it is a great tool. No tool is useful all the time and everywhere.
Productivity isn't just this sprint. It is the productivity of the next 10 years of maintaining code.
Testing is complex and it will take teams time to ramp up from "testing what they know how to test" to "testing where it is needed".
Enterprise rarely has top notch code quality. When the devs are a rotating cast of various experience testing TDD keeps the tests flowing. Testing keeps devs from quitting, users from bad experiences and, ultimately, costs down.
I've made it up as I went along. I really don't know much about formal CS (despite nearly 20 years of professional development experience) - I've never really studied it. I feel like a fraud most of the time.
Oh and on one job I lost the company $100k in my first week on the job.
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'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.
Well this one took off - I guess catharsis is a good thing, here's mine:
I'm addicted to the teletype-induced Unix shorthand, that is: rm vwls, and I get all OCD about my variable names being the same length to make the code look pretty at the expense of readability. Four character names (without vowels) seem to be my favourite.
Luckily my PoCs tend to get burned down by professionals before production!
I'll often get really excite about a new technology or language, seeing it's potential to help my career. Then I'll hit a roadblock early on and give up way too easily.
I start coding hoping that the solution comes to me as I go along. This leads to comment stubs everywhere of Just do this here without actually knowing how to do it. I usually just make an empty function with the return value I want in the meantime
That's similar to the first step of TDD :D
Writing a failing test with the expected return value
My second confession, I don't write nearly enough tests, so I don't know if this makes me feel more or less guilty 😂
When someone asks me for help and I can't figure it out I use stackoverflow solutions
Sometimes I overthink the smallest task, making myself slow. is this correct? Can I improve it? Is there any better way? Am I using the correct standard? it's updated? and I spend hours reading, searching.
When I code I try to finish a process without performing debugging and in the end perform tests "ohh run to the first time"
I try not to memorize things because I think they will change it later. So I'm dedicated to remembering how to search it in google. Too many frameworks.
I still depend on google and stackoverflow. And although I know English, I still look for words that I do not understand in Google translator.
I'm addicted to black magic. I'd rather spend two hours on a metaprogramming solution than 10 minutes on a straightforward solution.
😱
I still haven't learnt using gdb to debug if necessary. And when you work with legacy code with almost zero test coverage, it would be necessary...
More of an OPS confession, but I don't really like AWS. Sure, it's fine, but so much of it is overly complex and unnecessary for 90% of the folks/cases that want to use it.
I too often have to go back and fix typos I find in docs, comments, or strings because I forget to proofread.
I don't know if rebase is better than merge or not.
I have NEVER written code tests. Ever.
I write all my scripts in D because I hate all other scripting languages.
While I've been pitching Docker to my boss every since cgroups were introduced (a long time before Docker), I still don't understand how I could use it in practice
I'm hoping I can skip Docker as much as possible altogether. Not that it isn't important but there's a lot of hype. We went from "maintain your own server" to push-to-deploy (AppEngine, Heroku, AWS Elastic Beanstalk) to installing sofware over and over inside containers, to me it feels like a step back in terms of abstraction.
We need to move forward again.
Docker and k8s can be building blocks for that "future" but the same way we don't need to re-code every abstracted layer our apps sit on everytime we code something, I think containers are .
I subscribe to this view for the next few years:
Serverless + edge computing is going to be that abstraction for most apps, and in some cases it already is.
We're just at the beginning, that's all. We tend to equate serverless to function as a service, but it's so much more. Google has been offering serverless computing since 2008 with AppEngine, Heroku since 2007.
People use higher level languages all the time because of how more productive they are, even at the expense of "speed". Such productivity comes from abstraction among other things.
Don't know how big your organization is but this is a good article about pros and cons of serverless for startups: The business case for serverless.
ps. serverless is hyped as well :D
I say I love testing, but I don't do it on a lot of personal projects.
Might not be directly related to coding, but I spend way to much time on vim colors.