The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
So now I've got some tools to unleash some pretty advanced AI chatbots into some online forums which could make for an interesting social experiment, both in terms of the bot learning and evolving and in terms of people's reactions to it, and I was talking to my hubby all like "which group of unsuspecting plebes do I deploy one to first?" and then realized that there's no group of people that doesn't suck in some way such that it would poison the bot which led to the larger conclusion that people in general are kinda not so great.
But also, as I discover now, they are a typical way for the management to blame the developers for wasting time and not even have delivered a simple product yet despite all the development time already spent!
Are you talking about specs that change in the middle of the development cycle? Any non-trivial change to a spec should be met with the statement that the schedule must be revisited. If management disagrees, any sensible jury will see it as justifiable GBH if you kick them in the groin with all your might.
Yes, that's what I am talking about.
Moving spec are treated with a "how come this doesn't do it already" question?!
It's not like there is a nice spec document, it's n house development and spec are "discovered" as we go...
I am a contractor too now, it pays well!
1 year in my first 3 months contract
Anyway, ideally I'd like it to keep on going with a friendly ending! People there are nice too... Just there is a bit of stress right now, and the CIO has a slight tendency to do management by bullying, but only slight!
My experience has been be careful what jobs you take. I've actually had one outfit hire me to take the blame for a project that was sunk before I got there - of course I didn't know that when I took the job, but it became clear pretty quickly.
I was more careful about taking short term contracts after that.
I'm far from a stickler for process, but this sounds nuts. Are you saying that your users are in-house? And that they often expect you to anticipate their needs? I could see it to some degree if your development team regularly uses the software themselves, but even then it'd be a stretch given that every user has different priorities.
I am developing a database that is an import of other database. And it was used to good effect so far, implement all report that we were told to implement, etc...
And then suddenly, when 20 work days from release, it is discovered that this database is missing some super critical information.
Mind you it's not a bug in the existing code, it's that they expect this data was not part of the previous task, even going so far as explicitly saying it didn't matter. But now it is suddenly missing... :/
The import code keep on getting more difficult to update and database schema change take hours to run sometimes now... :/
I mourn the death of my old notebook that I used to toast EPROMs and run the terminal emulation for the old Elf. The power supply probably died when I moved it over to the desk with the Zwölf. Now an old desktop PC does its job. It also had been slumbering under the desk for years and collected dust, but it at least still has a parallel port (for the EPROMs) and a serial port (for the Zwölf).
Here is a picture[^] of my development setup on the PC, running Zwölf's first real program in emulation. The emulator is still really helpful, because it can very accurately emulate the software driven serial I/O. Unfortunately both the assembler and the emulator are not going to support Zwölf's modest memory expansion.
Zwölf now has some useful I/O, at the cost of one cheap MAX232, the rest is software. The program still needs more features, but the I/O routines already work fine, on the emulator and on the real thing. Now I have a formula to calculate the timing constants for any reasonable baud rate and clock frequency. I love RISC processors. They make such things really easy.
Little Zwölf has also already been showing some muscles. It tested its 32k RAM with all 256 possible values. At 1 MHz it needed about 22 minutes to check out 32k 256 times. Good news that the RAM is ok, but 22 minutes is quite a wait. It also makes the memory expansion a little questionable. So I exchanged the 1 MHz oscillator for a 6 MHz oscillator. That's 120% of the max. clock frequency. The processor did not even get warm and also had no problems with the noisy breadboard. And then it completed the memory test in under four minutes. Yes, CMOS is slow.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.