Timeline for Struggling to finish project, how to tell coworker?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 26, 2017 at 17:29 | comment | added | Daniel Jour | @Wildcard is right, take that advice! "I have numerous functions and subs that I've scratched but kept for reference so knowing which ones are used and aren't is proving difficult." --> version control allows you to delete currently unused stuff, but keeps it available if needed at some later time | |
| Jul 26, 2017 at 14:18 | comment | added | cheshire | @Mark very true. Definitely wrote down some lessons learned already on this one and will take some time to reflect once I've finished it. It is stressful but I appreciate the experience and lessons it taught. | |
| Jul 26, 2017 at 7:41 | comment | added | Mark | I know it looks bad right now but you should be glad you had this experience. Now next time you start a project, you will try a much cleaner approach. You will finally be able to understand certain standards for clean code that may have sounded unnecessary when you had never gotten to the point you're at right now in a project. It's surprisingly difficult to explain to inexperienced people for example why you don't leave code in your files "as a reference" or which comments are useless and which are important. Now you know better :D | |
| Jul 26, 2017 at 4:01 | comment | added | Wildcard | (a) Learn a version control system. I don't care which. (b) You as developer need to decide how to solve the problem you are faced with. Get data from your users, not proposed solutions that you then attempt to implement without your own consideration. | |
| Jul 25, 2017 at 22:44 | history | tweeted | twitter.com/StackWorkplace/status/889979716517728256 | ||
| Jul 25, 2017 at 22:04 | comment | added | Polygnome | "but the project began growing and becoming more complicated.". So, feature creep. Tell your collegue that the changing, growing requirements have made the project more complicated and it hus it will take longer. Also try to cut down the project back to its essentials. put code that somewhat works somewhere where you can retrieve it later when needed, but strip it back down to the MVP (minimum viable product). Then finish it. You can always go back to the finished product later and add more features, but bring it to a releaseable state by cutting down things that aren't actually needed now. | |
| Jul 25, 2017 at 21:34 | vote | accept | cheshire | ||
| Jul 25, 2017 at 21:33 | history | edited | cheshire | CC BY-SA 3.0 |
Update and thank you
|
| Jul 25, 2017 at 20:17 | comment | added | cheshire | @Johns-305 I would agree but in my case, my manager is very hands off with me. She really has no idea what I'm working on. I'm very independent in my role and essentially work on projects to support the people in my department. | |
| Jul 25, 2017 at 19:53 | comment | added | DTRT | It's probably more important how your manager feels rather than your co-worker. | |
| Jul 25, 2017 at 19:36 | comment | added | RandomUs1r | Just play it forward... the project isn't done because the scope blew up, because the scope blew up, the code needs refactoring, the code needs to be refactored to complete the project. My advice is never to admit wrongdoing, that's just not good in business culture for many reasons, obfuscate and make excuses, learn from your boss ;) Sounds terrible I know, but being able to handle negative situations with higher ups is a skill everybody above you has, so might as well start working on it now. | |
| Jul 25, 2017 at 19:36 | comment | added | Robert Sinclair | just a related piece of advice, i would recommend sketching out each module with a diagram (plenty of those online) and even creating supporting video tutorials for each module (and be okey with the fact that these videos will be out of date next time you code something) this way you can very easily get back into the large body of code while having a coffee and looking at the screen. Just do a screen capture and talk through the code. It's awkward in the beginning but a life saver when you have to review something you wrote a few weeks before. | |
| Jul 25, 2017 at 19:05 | comment | added | Seldom 'Where's Monica' Needy | Not an answer to your question, but in future I would recommend building up automated tests as you go along. They don't have to exercise scrap of code you have, but the pass-fail ratio for tests of your main functionality is a good indicator of when you need to stop, refactor, locate errors, rethink, etc. so you can avoid needing to solve many problems at once, which it sounds like you're doing now. | |
| Jul 25, 2017 at 18:22 | history | edited | IDrinkandIKnowThings | CC BY-SA 3.0 |
The side question is very off topic
|
| Jul 25, 2017 at 17:53 | answer | added | ooxi | timeline score: 2 | |
| S Jul 25, 2017 at 17:35 | history | suggested | DarkCygnus♦ |
added several relevant tags
|
|
| Jul 25, 2017 at 17:33 | review | Suggested edits | |||
| S Jul 25, 2017 at 17:35 | |||||
| Jul 25, 2017 at 17:25 | answer | added | Isaiah3015 | timeline score: 5 | |
| Jul 25, 2017 at 17:18 | answer | added | DarkCygnus♦ | timeline score: 33 | |
| Jul 25, 2017 at 17:04 | answer | added | Neo | timeline score: 39 | |
| Jul 25, 2017 at 16:58 | history | asked | cheshire | CC BY-SA 3.0 |