10 ms·
Stuck due to “knowing too much”
- pooriaazimi 14y agoI submitted it because it's exactly how I feel lately, and would like to know what others think about it. My current (personal/academic) project involves Node.js, (Iced)CoffeeScript, MongoDB (with Mangoose), PhantomJS, Mocha, Neo4j, Nutch, Solr, Hadoop and Mahout. All of them are new technologies and are changing rapidly and daily, and I find new stuff every day that forces me to change my APIs and the way I do things, and it's getting frustrating... It's the price you pay by using cutting-edge technologies and I accept that, but I can't help thinking that maybe Java+MySQL was a better/easier choice!
- gouranga 14y agoI suffer from the same trouble on occasions. I primarily deal with the Microsoft ecosystem which is volatile and fragmented at the best of times. I would kill to do something in good old java/mysql. A lot of the new ideas and principles are a mess. Don't get too absorbed - just use what lets you get the job done quickly and efficiently. a lot of it is just noise. I tend to find that a complete break from everything for a day helps. That and cider :)
- Morg 14y agoTry postgreSQL next time, at least it's ACID compliant ;)
- gfosco 14y agoTry using less things... How about just using Node and Mongo, and building the rest yourself? Node being in its infancy is a pretty good reason in itself to not tie yourself to the frameworks which are likewise infantile. I've got several production back-ends and a full-stack e-commerce site running with Node and MySQL only.
- engtech 14y agoExperience has taught me that if you want to get something done, you need to stay off the bleeding edge, or at the very least only drag yourself to the bleeding edge at controlled increments. The only thing that should be changing often is YOUR code. Everything else should be as stable as possible. What I find works best is playing leap frog: * your code is unstable / upgrade nothing * your code is stable, stop changing it and upgrade things one at a time test suites / regressions are a must.
- helper-method 14y agoA month ago I finished a project for university, involving Node.js - nothing more. At the beginning, I've started with Node.js, mongoDB, socket.io. express and connect. Half way through the project, I realized I would never be able to deliver in time. So I started to cut out technologies... first mongoDB, socket.io, express, and in the end, even connect. Even dealing with Node alone, I had a hard time finishing my project... but I did. I still got quite a good grade because in contrast to my fellow students, I was able to deliver.
- Aqua_Geek 14y agoI also found myself getting stuck and over-engineering. Now, I try to take a phased approach to development: 1. Make it work. 2. Make it good (visually or otherwise). 3. Make it fast.
- arethuza 14y agohttp://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
- slantyyz 14y agoThe saying Firmitas, Utilitas, Venustas comes to mind.
- chmike 14y agoThis good. But how do you handle it when designing a protocol and a data encoding ? You can't iterate.
- wpietri 14y agoAll good design comes from iteration. You can certainly do with protocols and encodings. Look at the very first published swing at HTTP, for example: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html http://www.w3.org/History/19921103-hypertext/hypertext/WWW/P... From today's modern perspective, it's laughable. And that was just the first public bit. Surely he iterated some on his own before putting that out.
- betadj 14y agoMake it fast only when you have to! I've seen too many projects focus on performance before traffic comes, most of time traffic never comes.
- powertower 14y agoSolution: Don't be purfect. Drop your fears. Enjoy yourself.
- cheald 14y agoDon't let "perfect" be the enemy of "good enough". A flawed-but-functional system that ships is empirically better than a perfect system that never ships.
- TazeTSchnitzel 14y agoSee: Linux vs GNU Hurd
- rguzman 14y agothis is easier said than done, but the key to avoiding analysis paralysis is to worry about building the right abstractions and only that. if the software is abstracted well -- ie it correctly represents the underlying problem at an adequate resolution -- then it becomes easy to say YAGNI in the short run with the confidence that refactoring or adding functionality will be straight forward later.
- Morg 14y agonot really. because you can over analyze what the right abstractions can be. it's only a matter of how abstract you want it to be, believe me. Analysis Paralysis is inevitable as long as you want to write the RIGHT thing. As soon as you accept "good enough, we'll upgrade later if necessary", you start moving towards the right thing. Anything that says perfect, adequate, right, correct, etc. is wrong and leads to the dark side.
- frankc 14y agoThe moderation on programmers.stackexchange.com is completely overbearing. How can a question about analysis paralysis be closed for off-topic? If stackoverflow is for technical question/answer, what is the point the linked stackexchange if not for discussion of a common programmer problem like this? I see stuff like this closed all time time and it's really annoying.
- droithomme 14y agoAgree completely. If that is "off topic for software development", then everything is off topic for software development.
- benjaminwootton 14y agoAgreed. If any StackExchange people read this please do something about this. It's a great site that fills a necessary niche but the moderation is killing it!
- noobiscus 14y agoIndeed; it seems every interesting question on there is removed as off-topic. Sounds like a key indicator that S-O is ripe for displacement...
- antidoh 14y agoAt this point it can't be done. StackExchange is the way it is by preference of the older controlling users.
- wpietri 14y agoNah. The company controls the software, which gives them plenty of ability to change the game dynamics. The only problem is a lack of will.
- antidoh 14y agoI think they've already given over control to their volunteers. Yes they could wrest it back, but I think their profit depends on not too much paid involvement. So it is what the senior members want it to be.
- hoopism 14y agoThis is a real thing for sure. The first 80% of a project is the fun/creative part. The last 20% is painful and usually where you make a product out of a project. Experienced developers know that starting a project means that ultimately you will have to do that 20% and they question whether it's worth the investment (before starting the fun part). New developers are usually blissfully ignorant and simply enjoy the first 80%. Some of them will take it beyond that... most will leave it as nothing more than an unfinished project. The fondness of directing others is really just the enjoyment of not dealing with the minutia of developing a robust solution.
- MortenK 14y agoVery sad that the moderators are closing such interesting questions, because they do not conform to their opinion of what should go on the site, even though the topic is obviously hugely popular and appealing to a lot of users.
- droithomme 14y agoIt's particularly outrageous because the given reason is "off topic for software development". It's quite clear from that judgment that the moderators don't know much about the topic and therefore are not qualified to hold a position of moderator on a board devoted to software development topics.
- stcredzero 14y agoA situation I have seen with well-educated novice developers, is that they think of "technical debt" as universally bad. That's not true. It's not even true for actual debt. Debt is only bad if it's your own long-term debt. One can also use short-term debt as a powerful tool. For example, it might be simpler for one to write an initial iteration of a program that's badly factored. Then, once you get the program running correctly, refactor it. It's much easier to know you're on the right path if your program runs correctly, and you have verification data-sets or unit tests. EDIT: Changed one short to long.
- geophile 14y agoSome lessons in software engineering take a long, long time to sink in. (For me, at least): - Don't generalize too early, which seems to address the original question pretty directly. - Don't optimize too early. - Maintainable > Correct > Fast. Maintainable = comprehensible. If it isn't maintainable, you won't know if it's correct. If it isn't correct, there's no point in making it fast. - Minimize state. Deriving something from scratch every time it's needed leads to far fewer bugs, and the bugs there are probably far more obvious. Cache only when you need to for performance. - Simplify as much as you can. This is the hardest one, because it can take a very long time to figure out all the ways in which a design that you thought was simple, turns out not to be. - Simplify some more: The usual statement of the "simplify" rule is "as simple as possible, but no simpler". I don't think that's right. If you see a nice simplification at odds with requirements, push back on requirements.
- mbenjaminsmith 14y agoI'm starting to see this more clearly as time passes. I've spent years developing the ability to "engineer" things and only now am I realizing that I've learned to "over-engineer" things. Writing software has taken on a life of its own that is actually counter to its purpose. I don't think in terms of simplification though, I see it as "write what you need, when you need it." But I absolutely agree that you should avoid generalization aggressively and optimization should rarely be on the table. I also agree about minimizing state. Do it all "on the fly" unless there's known performance hit.
- sklivvz1971 14y agoThe phrase you may be looking for: do all that stuff at the "last responsible moment".
- joshklein 14y agoThis is one of the most pernicious forms of procrastination, because it's hard for smart people to accept that perfectionism is a negative trait. The more self-worth you derive from your previous successful outcomes, the more susceptible your ego becomes to fear of future failures. Your amygdala is telling you that you are successful already, so don't shake the boat. Tread carefully and you'll always have an excuse for why things don't work out. You'll never have to admit you just couldn't do it. The solution is to divorce your self-worth from outcomes. Instead, derive self-worth from the process. We can have complete control over our actions, but never complete control over our outcomes. This is far easier said than done.
- vibrunazo 14y agoArrogance is probably the trait that most limits our intelligence. I've seen many smart people do extremely stupid stuff just out of fear of admitting they are prone to mistakes and failure. Humbleness is hard to master, but it's very important for us to try and practice it as much as possible. Potential of success = (Intelligence / arrogance) + luck
- tent1 14y agoWhat you're saying really strikes true, though I feel arrogant people can also be extremely hard working which can put them in better stead compared to others. Also, humbleness with a tint of arrogance or self belief can be a good mix – as long as you get the mix right.
- wpietri 14y agoModestly off topic: Can I say how much I have grown to hate StackOverflow and its cousins? Just like this article, half of my favorite threads on there are closed or have been deleted due to violating some sort of rule that is not unreasonable in theory but leads to obvious idiocy in practice. A great example of people losing track of the forest because of all the damned trees in the way.
- wpietri 14y agoMy solution to this is a simple kanban board. Trello.com is a good on-line one, but when possible I'll make them out of index cards or post-it notes on the wall. People think that a kanban board is a to-do list, but there's a subtle difference. The real heart of is limiting the number of work-in-progress items. That means that the backlog is less a to-do list and more a things-I-am-definitely-not-doing-now list. For me, every time I have one of those "It would be nice" thoughts, I write it down on a card for the kanban, throw it in the backlog, and forget it until the next time I make a prioritization pass. Most of the cards end up in what I think of as "the pit of nice ideas", the bottom segment of the board that never moves up because more important things always come up. For the curious, you can see a photo and a little more explanation here: http://www.quora.com/What-are-some-uncommon-ways-to-work-smarter-instead-of-harder/answer/William-Pietri http://www.quora.com/What-are-some-uncommon-ways-to-work-sma...
- swalsh 14y agoBloody genius!, I'm going to steal some post-it notes from the cabinet right now!
- wpietri 14y agoGood luck! Feel free to contact me with questions. My big starter tip is to make the work-in-progress column physically small. My current one limits the "working" and "on hold" columns to 3 items each. Whenever they fill up that's a sign that there's a problem in my process.
- Tloewald 14y agoIt just struck me we need "slackexchange" where we can trade expertise on avoiding work.
- yrizos 14y agoDude, we already have one: http://workplace.stackexchange.com/ http://workplace.stackexchange.com/ ;P
- h84ru3a 14y agoThe ideal to strive for is what we call the "Goldielocks effect". Not knowing too little. Not knowing too much. Knowing just enough to get the job done. In computing there will always be multiple solutions, and tradeoffs. What you want to aim for is "The simplest solution possible." In my experience, this is really hard for most developers. Maybe the smart thing to do is find someone who makes it look easy and trust their judgment. Again, my experience is that most developers are reluctant to do this. The question is not how much someone knows, it's whether they know "enough" to get the job done. Goldielocks.