I repeatedly get lost on details and making little, unimportant things perfect. The net result is having nicely written and maintainable code which I'm very proud of, but also which took 2-3x as...
I repeatedly get lost on details and making little, unimportant things perfect. The net result is having nicely written and maintainable code which I'm very proud of, but also which took 2-3x as long to write as I thought it would. ¯\_(ツ)_/¯
Part of my reasoning is that I'm investing time into improving my craft, so having been down a particular rabbit hole (even something mildly unrelated) I will emerge with greater perspective....
Part of my reasoning is that I'm investing time into improving my craft, so having been down a particular rabbit hole (even something mildly unrelated) I will emerge with greater perspective. Besides that, I have the luxury of being able to work on hobby projects at the moment, so nobody's bankrolling my idleness/breathing down my neck. :)
My general practice is to come up something quick and dirty which solves the problem and contribute to the product then allocate resources to refactor it and make it pretty later. Usually refactor...
My general practice is to come up something quick and dirty which solves the problem and contribute to the product then allocate resources to refactor it and make it pretty later. Usually refactor happens when I already learned more context about the problem so I can generalize the solution and make it elegant. Also, experience helps you to come up with an elegant code as a first iteration.
I have a similar issue where I'll focus so much on one feature that I forget I wanted to refactor other portions, so I end up with one super well-documented and executed feature, but the others...
I have a similar issue where I'll focus so much on one feature that I forget I wanted to refactor other portions, so I end up with one super well-documented and executed feature, but the others are still a dumpster fire haha
I have a similar issue where I'll focus so much on one feature that I forget I wanted to refactor other portions, so I end up with one super well-documented and executed feature, but the others...
I have a similar issue where I'll focus so much on one feature that I forget I wanted to refactor other portions, so I end up with one super well-documented and executed feature, but the others are still a dumpster fire haha
For projects where time isn't the limiting factor (read: non-work things), my strategy is making three builds: First two builds in scripting languages. One that gets the job done and nothing more,...
For projects where time isn't the limiting factor (read: non-work things), my strategy is making three builds: First two builds in scripting languages. One that gets the job done and nothing more, then go back and look at it and carefully craft another version that's "good code". Then I'll go back and re-implement it in a lower level language once I know where every piece fits so I can get it right the first time.
It depends on the project I'm working on. If it's a personal project, I generally use a language I really enjoy writing in, and I'll put in some extra effort to make it pretty. It's not uncommon...
It depends on the project I'm working on. If it's a personal project, I generally use a language I really enjoy writing in, and I'll put in some extra effort to make it pretty. It's not uncommon for me to go back to the previous thing I wrote, just to rewrite it in a nicer way because I just learned a more elegant way to deal with an issue.
For work, I generally care less about code quality, and more about getting the product in a state that works for the customers. They are after all the reason I am able to get my money. I still tend to take some additional time to write more tests than necessary, to enforce some level of good code to myself (forcing to make more, smaller and testable code of itself is a good thing that improves overal codebase quality).
For university, I generally just make the code just good enough for the teacher's to praise me on some particular thing they wanted to see being used, and a product that works Good Enough(tm) for a good grade. I don't really care about the overal quality as much, as it's not going to be used or read by anyone but a handful of people for a very short amount of time.
Interestingly for me it's the other way around, with a personal project my first goal is to get a proof of concept up and running, so I don't have the leisure of planning thinking everything...
Interestingly for me it's the other way around, with a personal project my first goal is to get a proof of concept up and running, so I don't have the leisure of planning thinking everything through, but with a work project there usually is no testing until the project is more or less complete, plus I have a pretty clear idea of the requirements, so I'm able to be thorough.
When I'm working on the frontend of products, I care about the product's final state (UX, UI). Unless I'm compromising the performance in some way, any hack is good to go. When I'm working on the...
When I'm working on the frontend of products, I care about the product's final state (UX, UI).
Unless I'm compromising the performance in some way, any hack is good to go.
When I'm working on the backend I usually lose myself in trying to abstract code that really wouldn't need it. And I know it perfectly but it's just like solving a puzzle. I don't do it always but a good amount of times out of the total :P
More like there is so much lack of standard that often you have to. You don't want to know how many swearing I've done to make electron on angular work for USB and serial port on fucking windows....
More like there is so much lack of standard that often you have to.
You don't want to know how many swearing I've done to make electron on angular work for USB and serial port on fucking windows.
Took all my will to not go for some bad ugly hacks.
I have a love-hate relationship with electron, and not even as a developer, as an end user. I really like how electron enables cross platform apps etc, but I like native apps more so.
I have a love-hate relationship with electron, and not even as a developer, as an end user. I really like how electron enables cross platform apps etc, but I like native apps more so.
I'll be honest and say that I care most about the product and a by-product is my code is pretty sloppy. We're a mall company and at this stage, it's worth taking on tech debt to hit certain...
I'll be honest and say that I care most about the product and a by-product is my code is pretty sloppy. We're a mall company and at this stage, it's worth taking on tech debt to hit certain deadlines/ meet certain demands.
One the reasons I'm leaving that company soon though is that I feel like I'm not learning how to do a good job just a quick job. I think I'll always care about the product/ overall business more than the nuts and bolts but I'm hoping that in future roles the best thing or the product will be to invest in performance, robustness, user experience and maintenance
I care more about the code itself. For some people programming is a means to an end. For me, the product/project is a means to an end, where the software itself is the end. This means that I often...
I care more about the code itself. For some people programming is a means to an end. For me, the product/project is a means to an end, where the software itself is the end. This means that I often just sit and review my code for a long time, often multiple times for a given file until I'm happy with it.
I can of course also get work done quickly. When using a language I'm familiar with I'm very efficient. But given the time to do so I will try to make my code as elegant as I can.
Depends really. If I'm building something for myself, then I focus on building it good, making it something I can be proud of. If I'm being paid to produce something, the end result is far more...
Depends really. If I'm building something for myself, then I focus on building it good, making it something I can be proud of. If I'm being paid to produce something, the end result is far more important. After all, the customer isn't paying for pretty algorithms
Though maybe really they are, if a problem comes because a focus on speed rather than nice code, who will they blame? And even if it's not about blame, the next person working on it may have to...
Though maybe really they are, if a problem comes because a focus on speed rather than nice code, who will they blame? And even if it's not about blame, the next person working on it may have to spend more time because of the current focus on speed, should the current developer implicitly have the responsibility to keep that in mind?
I prefer neatly written code which can be maintainable. Features are owned by the product owner and as a programmer, I do my job by keeping my code clean and readable. I always try to make sure...
I prefer neatly written code which can be maintainable. Features are owned by the product owner and as a programmer, I do my job by keeping my code clean and readable. I always try to make sure that a new programmer can understand my code. If I copy code from somewhere, I try to put the link to that post or page in comments and explain why I did that.
Coming back to the product, I do love the end product. I believe that good code created good products.
I care more for solving the broader problems, then the code and then the finished product. But again, the finished product has to be user friendly and reliable, else the effort to make it would...
I care more for solving the broader problems, then the code and then the finished product. But again, the finished product has to be user friendly and reliable, else the effort to make it would have been somewhat wasted.
I repeatedly get lost on details and making little, unimportant things perfect. The net result is having nicely written and maintainable code which I'm very proud of, but also which took 2-3x as long to write as I thought it would. ¯\_(ツ)_/¯
My boss both complains and compliments me - sometimes in the same breath - for similar practices.
Part of my reasoning is that I'm investing time into improving my craft, so having been down a particular rabbit hole (even something mildly unrelated) I will emerge with greater perspective. Besides that, I have the luxury of being able to work on hobby projects at the moment, so nobody's bankrolling my idleness/breathing down my neck. :)
True, getting good coding practices also helps you churn out similar features in a shorter time, with better practices overall!
My general practice is to come up something quick and dirty which solves the problem and contribute to the product then allocate resources to refactor it and make it pretty later. Usually refactor happens when I already learned more context about the problem so I can generalize the solution and make it elegant. Also, experience helps you to come up with an elegant code as a first iteration.
That's how personal projects are for me, but I don't often get to the refactor part...
I have a similar issue where I'll focus so much on one feature that I forget I wanted to refactor other portions, so I end up with one super well-documented and executed feature, but the others are still a dumpster fire haha
I have a similar issue where I'll focus so much on one feature that I forget I wanted to refactor other portions, so I end up with one super well-documented and executed feature, but the others are still a dumpster fire haha
For projects where time isn't the limiting factor (read: non-work things), my strategy is making three builds: First two builds in scripting languages. One that gets the job done and nothing more, then go back and look at it and carefully craft another version that's "good code". Then I'll go back and re-implement it in a lower level language once I know where every piece fits so I can get it right the first time.
It makes prototyping new things really enjoyable.
It depends on the project I'm working on. If it's a personal project, I generally use a language I really enjoy writing in, and I'll put in some extra effort to make it pretty. It's not uncommon for me to go back to the previous thing I wrote, just to rewrite it in a nicer way because I just learned a more elegant way to deal with an issue.
For work, I generally care less about code quality, and more about getting the product in a state that works for the customers. They are after all the reason I am able to get my money. I still tend to take some additional time to write more tests than necessary, to enforce some level of good code to myself (forcing to make more, smaller and testable code of itself is a good thing that improves overal codebase quality).
For university, I generally just make the code just good enough for the teacher's to praise me on some particular thing they wanted to see being used, and a product that works Good Enough(tm) for a good grade. I don't really care about the overal quality as much, as it's not going to be used or read by anyone but a handful of people for a very short amount of time.
Interestingly for me it's the other way around, with a personal project my first goal is to get a proof of concept up and running, so I don't have the leisure of planning thinking everything through, but with a work project there usually is no testing until the project is more or less complete, plus I have a pretty clear idea of the requirements, so I'm able to be thorough.
That's part of what I meant by code.
When I'm working on the frontend of products, I care about the product's final state (UX, UI).
Unless I'm compromising the performance in some way, any hack is good to go.
When I'm working on the backend I usually lose myself in trying to abstract code that really wouldn't need it. And I know it perfectly but it's just like solving a puzzle. I don't do it always but a good amount of times out of the total :P
That's probably at least partially because frontend of web development can only really be made using hacks upon hacks.
More like there is so much lack of standard that often you have to.
You don't want to know how many swearing I've done to make electron on angular work for USB and serial port on fucking windows.
Took all my will to not go for some bad ugly hacks.
I have a love-hate relationship with electron, and not even as a developer, as an end user. I really like how electron enables cross platform apps etc, but I like native apps more so.
I'll be honest and say that I care most about the product and a by-product is my code is pretty sloppy. We're a mall company and at this stage, it's worth taking on tech debt to hit certain deadlines/ meet certain demands.
One the reasons I'm leaving that company soon though is that I feel like I'm not learning how to do a good job just a quick job. I think I'll always care about the product/ overall business more than the nuts and bolts but I'm hoping that in future roles the best thing or the product will be to invest in performance, robustness, user experience and maintenance
I care more about the code itself. For some people programming is a means to an end. For me, the product/project is a means to an end, where the software itself is the end. This means that I often just sit and review my code for a long time, often multiple times for a given file until I'm happy with it.
I can of course also get work done quickly. When using a language I'm familiar with I'm very efficient. But given the time to do so I will try to make my code as elegant as I can.
Depends really. If I'm building something for myself, then I focus on building it good, making it something I can be proud of. If I'm being paid to produce something, the end result is far more important. After all, the customer isn't paying for pretty algorithms
Though maybe really they are, if a problem comes because a focus on speed rather than nice code, who will they blame? And even if it's not about blame, the next person working on it may have to spend more time because of the current focus on speed, should the current developer implicitly have the responsibility to keep that in mind?
Ugh, I hate stupid UX designs!
In my experience they go hand in hand. People who profess to favor one over the other tend to achieve neither.
I prefer neatly written code which can be maintainable. Features are owned by the product owner and as a programmer, I do my job by keeping my code clean and readable. I always try to make sure that a new programmer can understand my code. If I copy code from somewhere, I try to put the link to that post or page in comments and explain why I did that.
Coming back to the product, I do love the end product. I believe that good code created good products.
I care more for solving the broader problems, then the code and then the finished product. But again, the finished product has to be user friendly and reliable, else the effort to make it would have been somewhat wasted.
Letting you know you double posted this comment.
There's a bug report about double posts.