Thanks Chris, I'll certainly put forward your good ideas to our DBAs. But ... you answered how, not why? Implicit in your answer is the acceptance that the live database should reflect what it 'should' be from Dev. What are the reasons (technical or business) why a live system should reflect exactly what is in Dev, when those superfluous tables are not really harming the operation of the live system? Any insights would be appreciated.

This isn't a question about how to detect and prune unused tables in a live database. I'm more interested in the reasons why it should be done at all. Here's some context. In our development environment we maintain a production database from which a schema and upgrade script is generated. When a database is upgraded it will create or alter existing tables on a live system, but not remove any tables. After a debate about how it could be done and whether it should be done, I was struck by my colleague's statement of 'a lot of effort and potential pain, for not much gain'. There is of course the obvious risk of removing a table that really is used and causing a live system to fail. There didn't seem to be much debate on whether defunct tables should be removed from a live database on the internet. Apart from those of us who are hopelessly OCD about these sort of things, are there any good reasons for running the risk of removing defunct tables from a live system?

One problem with NuGet is Visual Studio itself. It assumes you will organize everything at the solution level, so if you're working with a code base with multiple solutions, there are package folders littered everywhere! Then there are out and out bugs in MSVS. Try centralizing your downloaded packages into one package folder and it all starts going south... Anyway I've done pretty much what Marc describes above. I create a ThirdParty solution that I use to download all NuGet packages I want to use. They all get downloaded into the ThirdParty solution's package folder, where literally everything in the package folder gets put into source control. This pattern allows me to download and keep multiple versions of the same NuGet package so that legacy applications are able to use an older version if, for some reason, it is withdrawn. From there, any other solutions that want to use a NuGet package will simply use a file reference for the dll directly from the ThirdParty package folder. Source code from other vendors are included as projects to the ThirdParty solution and again those libraries can be referenced from a solution as a file reference.

Yeah I remember typing programs from magazines into my ZX Spectrum. They never ever worked and I was always left scratching my head. My first program on the ZX Spectrum was a D&D character generator. Had I the wit to sell it, or port it to another platform, I could have made a bit of money out of it. Always thought I was going to write my own game. Forty years on, having worked as a software developer in more companies, projects and technologies than I dare to remember, I'm still chasing that dream.

Don't worry about what the other boys do, worry about what you do. Use your gift by all means, but don't brag or criticise others for not being a clever as you. Help them because one day you'll need someone to help you. No-one is invincible; if you pay it forward it will come back to you by another route.

I suppose I'm well late with my advice but here are my thoughts. Programming is an unusual profession because it doesn't necessarily require qualifications to gain entry. Experience counts for an awful lot. I would say pursue your studies (HNC) at night school - it is what I did - but now you must focus on gaining that entry. I don't think a lack of experience has to work against you, it could be an advantage because you will be so much cheaper. At 28 you ought to be able to present yourself as a reliable and mature person that an employer will be able to rely upon. Having said that, you may find that you have to attend a lot of interviews before you get anywhere. Would be employers are incredibly cagey and interview practices are notoriously subjective. At one point in my career I did something in the order of 40 interviews before I made any headway. It probably won't be that bad for you because I had a number of mitigating circumstances, but even so don't be disheartened when a would be Senior Dev pulls your wings off because you didn't 'get'his pet problem. Agents can be tricky to work with, but a good one can really make the difference. Just be careful that they are telling the truth about you to a prospective employer. To begin with I would suggest you may be able to pick up short term contracts at a low rate. Possibly you could discuss an extended probation period with a full time employer. Working from home might be an option. Be careful of picking up work from places like People Per Hour. Make sure you carefully scope any work. Expect to have to travel, but you might be surprised how many local firms there might be. You might also find that there are local firms that might want a bit of IT done on the side for cheap. You may also consider testing automation (Selenium, simulators) as a route into development. In your situation I would avoid any jobs that are directly related to supporting an existing product. That will come later on anyway and there won't really be the opportunities to flex your new development muscles in the way you would like. Don't get me wrong, support can be a very challenging environment but it often doesn't get the respect or kudos it deserves. If you wind up as that support engineer there is a very real possibility that you will be passed over on the really good development opportunities. Finally, remember: software development requires confidence in yourself and your abilities. If you lose that confidence you're toast as a developer. Never ta

Am I too late? I wouldn't take the counter-offer. You decided to leave that company for a good reason and always best to leave on your own terms. You can't worry about whether a route to management would be better in one job or another. As far as I can tell its never a simple progression from A to B to C. Luck and personality have a lot to do with whether you wind up in management or not. Unless or until it actually happens for you, just focus on being the best developer you can be. By all means prepare for being a manager - business studies & management courses perhaps. If you're honest are you really talking about being your own boss and/or earning more money? If so then there are probably better routes into management.

As I say to my boss: "If you don't want me to refactor, then don't make me look at the code". Always try to remember a few things. You're likely in that code because something isn't right anyway - either a fault or a change request. You're really good at what you do, and that's why you're the one being asked to fix the 'garbage' code. Keep faith in your own abilities, software development is all about confidence. The moment you doubt yourself, you're toast.

MVVM is incredibly difficult to get right and even after 8 years of tinkering with it I'm still learning! Some developers don't have the time, patience or permission to waste time getting it just right, when going to the code behind gets the job done. I found the learning curve for WPF/MVVM incredibly steep and I'm sure that puts off many beginners. Part of that learning was the realization that MS put WPF out there half-baked and then moved onto something else. I find that over the years I've collected or developed so much code that could have easily been rolled into the framework at some point. I find XAML particularly obtuse and difficult to work with at times. If I could change or improve two things with WPF it would be to simplify the XMAL syntax and dependency properties - the real place where 'code behind' should go. It is such a shame that this technology isn't as accessible as Winforms because it can be incredibly powerful. Then again, maybe MS should admit that really the way to go is HTML5/CSS and simply replace what XMAL does with that. Unless (I'm not quite up to speed with Universal Apps) there is something already for that?

A few years ago I really, really, finally had to learn web technologies after spending most of my career in the *Nix, C/C++ and Informix world. I was utterly horrified to learn that the internet is essentially cobbled together with a mish-mash of scripting languages. In some software houses its like the Wild West! In the end you have to be responsive to the job market but a little part of my programming soul died when I had to work with Perl on Apple Macs. If you have to make the transition into a new environment like Python, then so be it. But lets not kid ourselves that it is the best thing since sliced bread. Learning a new fangled scripting language is just another obstacle to earning a living IMO. I'd much rather the industry settle on one language and set of frameworks and make it universal. Then I can spend my time doing my job and learning to do it better, instead of having to keep back tracking over the same basic stuff over and over again. The patron saint of Software Developers should be the mercurial David Bowie forever singing "Changes". Whenever a another smart arsed dev invents a new language, just for fun and says this is cool everyone should use it, all I hear is Madonna singing "Like A Virgin".

I collect, or invent silly names that I might use in test data. Sometimes I base the name from a dead musician or sometimes someone I've known. Others are just silly names. Names like "Amy Wino", or "Hurt Cobain" remind me of the ZX Spectrum game "Rock Star Ate My Hamster". "Gribble" was a boss I've worked for, and "Baboonboy" is an actual name in the world. "Lolly Pop", "Ham Salad" or "Porkie Sausage" are just silly. Let's face it, testing is a chore for us developers; anything to get through those days ;)

Possibly a cut and paste job from the internet by someone not familiar with C#, .NET or programming in general. Could well be a port out of C, C++ or VB6. Things like a private static method and module/global variables could be an artifact of another language.

To be fair some of the Microsoft classes can be difficult to use. After a few months battling my way through problem with the configuration classes, I really regretted my decision to use those MS classes. In future, I might roll my own or find an alternative. My point being, is that we all will have bad experiences that influence our future decisions. In time, you may forget what those reasons were and just stick to the libraries and patterns you're familiar with. Arguing over performance was the wrong argument to have. You should have really dug into the statement 'weren't any good.

You your side projects don't necessarily have to achieve an end product to be a useful exercise. I often start side projects to explore coding styles, patterns and architecture and new technologies. Because my side projects are in my own time and under my complete control, and I have the freedom to pursue any avenue without fear of cocking up an existing code base or missing a deadline. This is how I've explored the fusion between MVC, Razor and Angular. Or how I might practically implement an event source pattern. The actual projects are disposable, but I've learnt enough in the sandbox of a side project to be able to apply the concepts I've learnt on a professional project. Occasionally a useful application comes out of the side of this activity. If I'm really lucky, one day I'll stumble onto a saleable product.

Other posters have pointed out that generally fixes should be propagated forward from dev->test->release->production. However, I do recognize that sometimes a quick fix is done in production, for whatever reasons. This can happen a lot with scripting languages and undisciplined devs and support staff. In your scenario, I would have probably have tried to sync the production changes back into the appropriate branch and then apply fixes. If I was unsure of the outcome of the merge back from production then another branch could be easily made to test the merge out. If all else fails, don't forget that you can step out side of source control and manually apply back production changes if necessary. The git merge tools are usually very good, but sometimes things can get confusing. When you do attempt the merge back from production, make sure the dev that applied the changes is present if possible. Together verify the end result of the merge is the intended fix to production. In other words, don't guess at what the final merge product should be.

There are lots of criticisms that you could make of agile and supporters would suggest that you are not doing it properly. But from what you've posted, it seems more like you have a bad manager, but you know this already. I'm guessing you're dealing directly with your boss? Agile is just a smoke-screen for do it all as fast as you can; use weekends and evenings for all I care? If you can, you need to educate your manager with the true costs of software development in terms of time that it takes to do the job properly. You need to try to establish that there is an overhead in constantly re-writing the same software when requirements change. Granted, this is a part of the natural evolution of software, but (for simplicity's sake) at the very least you should be able to confirm the version you've just released before you start working on the next version. Changing team company or team culture won't happen overnight. It will be a process over a long period of time. Collect your data and facts before having that argument. Hope this helps.

Maybe you've got a few things the wrong way around. Are you asking too much of the team in too short a space of time? If this sprint and the one prior is only delivering 40 points instead of the anticipated 160, then perhaps that is too much. Even if you didn't do unit testing and just went straight to system testing would the 160 be realistic? Remember to apply S.M.A.R.T. objectives for your team. That might help keep things focused. You're probably doing this anyway, but direct your team to complete the most critical changes in a sprint first, so the least critical changes can roll over. If you're delivering the important stuff then perhaps your management will overlook the shortfalls in delivery. At least for a while. Take another look at the project plan/road-map. Has enough time been allocated to testing? I'd say a rule of thumb would be 1 hour of dev should have 1 hour of testing. Even better to have 2 hours of testing. You could consider the act of maintaining unit tests goes into part of the testing time. Maybe that is the difference between 160 and 40 points - there is a whole bunch of time for unit test development that isn't accounted for. You may be able to justify an extension to the development based on actual performance and gaps in the project plan. If the subject of extending the team comes up in that context, definitely go for more testers, or more developers dedicated to supporting the testers and/or unit tests. Testers and junior devs tend to be cheaper so you could get more bang for your buck there. As you've pointed out in your post, a lot of time can be sunk into testing one way or another. Even if you didn't use unit testing & CI there would still be a test team that is likely to not inherently have the skills necessary to reset systems, write scripts and generate test data. Inadvertently the testers could be a drag on your dev team, so make sure they have access to dev skills. Even if that means assigning a developer specifically to that role. To put it another way, sacrifice one dev to testing so everyone else can get on with their jobs! If this still doesn't get the delivery you want, then don't be afraid to ditch the unit testing entirely. Your team will hate it. Maybe it will bite you in the arse later; but later is for those that survive the deadline. However, if you do, then make double sure that your system testing is giving you good coverage. Finally, my old PM used to say that the first thing he did with a failing team was to reduce (not

Depends upon whether I'm going to be hiring a junior or senior dev and you don't specify. You don't really say what kind of role the candidate would be going into. e.g. support, green-field development. I'd be more inclined to hire developer B because of more experience, but experience doesn't mean as much as people make out when technologies keep changing every 5-10 years. Consider, every software development team has its own 'culture'. That is to say, their own way of deployment, monitoring and managing faults, source control, standard coding habits etc. Define what your own culture is and interview both against that criteria. That might be more informative than interviewing against qualifications or any other types of arbitrary indicators you've dug up off the internet.

Not officially, but sometimes something interesting crops up. Lately we've been working on a 3.2.1 patch of a product. So we're calling it the 'Ted Rogers' patch.

Here are a few tips. If nothing else fix layout issues - indentation, spacing etc - and add (sensible) comments where it makes sense. The act of tidying up layout and having to think about what a small section of code is doing, in its own right, will help build your understanding of the bigger picture. From there is probably won't take long for you to start spotting refactoring opportunities. If you do decide to make changes, start with the small trivial things since these will often be overlooked or tolerated for the sake of the big things. Build up a testing regime for your changes BEFORE you make the changes. Don't focus on code structure or control too much. That will become obvious. The key to any code base is how it organizes its data and moves it around. This you can analyse and diagram. Remember, fundamentally all any software is really about is moving data from A to B. With this in mind, pay special attention to the interfaces between modules, components and systems. This is likely where the most problems are. Especially when either side of the interface has been independently developed. Also look for places where data is transformed from one form to another e.g. conversions, lookups. Another source for faults. If you are able to run the software, another way of gaining understanding is to include detailed logging/tracing of the software's operation as it is running. In this context, look to trace the initial state of variables and when variables change, the function calls (including explicit variable values) and function returns and error events in the code. Those three categories of logging should be enough for you to hone in on most problems with the code when it is running. This is ofc verbose and has performance implications so make sure it can be turned off or removed from the release product entirely. Finally, study design patterns and identify where they have been used in the code. Either intentionally or unwittingly. You may be lucky and the patterns may be explicitly named e.g. WidgetFactory or WangleAdaptor. Design patterns are not the be all and end all, but they are a useful shorthand for common development problems.