Tag Info

New answers tagged

1

Holding configuration data like this externally to the application code is quite common. Since you have to persist this information somewhere a RDBMS is as good as anywhere, especially if the application is using the DB for "real" data already. Having five tables for your putative five levels of menus is not a good idea. It is inflexible and you can ...


4

Your menu is essentially a tree, so could be stored in a single database table: ID (number, not null) PARENT_ID (number, can be null) DESCRIPTION (text) where PARENT_ID is null for top-level menu items. You might need one or more additional columns to hold the behaviour you want to associate with the menu items (e.g. an action ID, command name or URL).


-2

Two more suggestions, I'll bet at least one of these you haven't done. 1) Put a bug tracker in place and teach your boss to use it. This can be part of the conversation about how you screwed up, have learned better and are going to fix it in a planned manner 2) Start using version control, although hopefully you are doing so already. There are heaps of ...


-1

Your question says: "Started wrong, should I start over" while the additional text actually says "Finished project, but did it wrong, should I start over". For the question headline alone: If the amount of programming work that you have done is small compared to the total work needed, then starting all over will make sense. That happens a lot when the ...


-2

You're a beginning web developer, with no good developer present to advice you, your boss hired you knowing this fully well. I think you are doing just as well as anyone could expect you to do. Actually, the fact that you have the insight that the job could have been better, and that you actually learned things that would allow you to do it better, means you ...


2

In my opinion it's better to "master" one language first. Not to the point where you know its every single peculiarity, but a good target would be to be able to understand around 90% of a well-written piece of code without looking stuff up, and to be able to write your own code without constantly referring to books or online resources. Don't spread ...


0

This is what I would do personally: Quit, make an excuse and give up (you can even give back part of your salary so you don't look bad) Clean your code as much as possible Make documentation on all the good parts of your work like your good design, good ideas, etc... Why do I suggest all of these to you? Because think about the future. There will be ...


4

For reasons that others have thoroughly explained, it is time to finish the project and ship it, painful as that may be. I would just like to emphasize that testing the app is also part of "finishing" it. If significant pieces of functionality haven't been thoroughly exercised and correct results confirmed, then you're justified in your concern that people ...


-1

To answer your question: as so many others have said, no. Ship it, and clean it up bit by bit in the process of fixing bugs. Additionally, while books/StackExchange/webforums are good learning resources, you are likely to find that nothing can match the learning you will receive from working (or even just discussing work) with other programmers. Finding and ...


6

Most of what I would say in response to your question has been said by others. Read "Things You Should Never Do, Part I" by Joel Spolsky (along with some of his other posts about "architecture astronauts"). Remember that "the perfect is the enemy of the good". Learn to refactor incrementally. Shipping is important, etc. What I would add is this: you've been ...


9

You're doing good. You say that your code works, and it's almost ready to ship, right? And you perceive that your code may be vastly improved. Good. Your dilemma much reminds me of my first experience with freelancing (getting hired while in my 2nd year at uni to create a multilingual POS system). I went through endless questioning as I was never satisfied ...


21

I forget where I first read it, but I just wanted to echo, somewhat more forcefully, what other people have said: Shipping is a feature. There is nothing worse than that one guy who keeps "cleaning up" existing (possibly hacky, ugly, dirty) code that works perfectly well, introducing new bugs, etc. What matters in the real world is getting your job ...


2

This is normal. The customer wants something that does this and that but isn't exactly sure of the best way to accomplish this and that. You are the expert, they are relying on you to fill in the missing pieces of their vision. You need to give them enough to work with so they can say, yes that's what I wanted. Usually that's a canned functioning UI ...


1

Consider Joel's advice in The Iceberg Secret, Revealed. Make the template look exactly as nice as how well the back-end is implemented, and provide all such screenshots and progress reports in this manner. Use wire-frames, plain-text placeholders, and similar ugliness in place of missing or broken functionality. Instead of telling your client, "it will ...


-1

Your boss was aware of your experience level when he hired you. Just express your concerns, and let him know you're nervous about it. Also let him know how much you've learned and how much better you can do the next project.


14

I [...] read Uncle's Bob clean code. I'm having this persistent thought that I have to rewrite the whole project. This book has a section named, very appropriately, "The Grand Redesign in the Sky". Don't try to rewrite everything because, in the unlikely event that you have the time to make it, you will face the same problems anyway. When you ...


4

If you're really interested in the dilemma you have, you should also read "Lean Startup". A lot of the advice that you're being given here will resonate with you more if you read that book. Basically, resource burn-rate is your worst enemy and nothing is more valuable to you and your organization than end-user/customer feedback. So, get your product to a ...


20

Every project leaves you smarter than you were before. After every project you will have accumulated more experience which would have been very handy when you had it from the start. I know that it is hard to not revisit everything and apply what you have learned. But remember: Perfect is the enemy of good. For the client it is always better to have a good ...


191

You have stumbled on the achilles heel of most CS educations: they teach you the tools and techniques, but not the trade. Building software is a craft, one which you only acquire through years of practice and the experience of having your software used (users are much harsher critics than teachers). Building software is also quite often a business, one where ...


48

Whenever you start from scratch again, you'll almost certainly make the same amount of mistakes (or more because the Second System Syndromme tends to kick in). They will be different mistakes, but there will be similar amount of time to spend with debugging and similar despair about how it's not a good fit. It will also delay deployment into production (or ...


89

Sounds like every second system that has been thrown at me to fix. Relax, this happens to a lot of people. A junior thrown in at the deep end with no experience, who has no help, no support and no guidance isn't exactly a recipe for success. Hiring and expecting a junior programmer to build a brand new system from scratch that works well, performs well and ...



Top 50 recent answers are included