|
AMARANTHINE is the correct answer - care to explain the clue for the others?
(I'm assuming you just unscrambled the anagram, hence the difficulty in spelling)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yeah, worked out the anagram but referred to a song called Amaranth by one of my favourite bands which I vaguely recalled meant undying flower. I just added the 'ine' to the end as a typical chemical name.
Then... I cheated slightly by looking it up to check about the purple / red colour bit before posting.
Andy B
|
|
|
|
|
|
I think I can tell what you are surfing for today...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hey, it wasnt me bought up the subject of purple-red cocktails!
|
|
|
|
|
We had an kickoff meeting regarding a new software development,
Requirement was locked in ( at least on paper) and the meeting was called in to come with some concrete architecture.
It was chaired by one of our Legend Architect.
As the meeting started, it turned into a brainstorming among developers and he being just silent. Finally we zeroed on a architecture and we all felt it is the best considering all the constrains.
The "legend" said "Good, Put this on paper and lets start fine tuning among with various stake holders" That's was his only statement till now and he contributed nothing else.One Dev made a snide remark, saying why was he there and earn so much when he did not even come with the architecture which he was supposed to.
He replied, " I am paid to cover your A$$ when sh1T hits the fan and to clean the mess. Also If I come and trust an architecture on you, you would be going multiple rounds objecting it. The best solution is always when it comes from you rather than someone else telling what/How you should do.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
When the sh1t does hit the fan he can always say: "What do you guys suggest? I wont force a solution on you, you would only complain"
... such stuff as dreams are made on
|
|
|
|
|
Well have to wait and see what happens then and his reaction.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
super wrote: The best solution is always when it comes from you rather than someone else telling what/How you should do.
Exactly. Clearly he understands more about architecture than just software architecture. What you experienced there was an excellent example of social engineering.
Marc
Latest Article - Merkle Trees
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Quote: social engineering I do not think it means what you think it means.
Sounds like basic leadership to me... let the people who will do the work brainstorm it. If you see any major issues help guide them, else sit back, observe, see who is the major contributor, who is the greatest roadblock, etc...
Mark
Just another cog in the wheel
|
|
|
|
|
I hate it when junior people try to put you on the spot and make you look bad. The Legend took care of business the right way.
|
|
|
|
|
Either of Marc's or J's replies could be correct, in this matter.
The deciding factor would be how good this "legend" actually is at his job.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
If you consider that this guys is described as a "Legend" right off the bat, then there's a good chance that Marc's assessment is the correct one.
Hope so for the sake of the developers and the project, anyway
|
|
|
|
|
Given how much I know now, I find it hard to disagree.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Quote: The best solution is always when it comes from you rather than someone else telling what/How you should do.
Humans tend to hate to be commanded to do something; even if it is right thing. One would rather fall flat on his face; redeem; be enlightened than listen to advice.
Your legend probably knows this.
Interesting guy. I would like to meet him somehow someday.
|
|
|
|
|
Sounds like a seasoned veteran who knows his stuff. Also, he seems to know how to get the junior developers participating to help them learn. One of my great mentors taught me a great lesson: "teach the juniors to replace you".
|
|
|
|
|
Much easier to get buy-in for a idea from the consumers of a thing rather than forming the consumers around an idea of buying in. The former almost always will result in the fewest rebels to the process while the latter is almost always going to produce the greatest rebellion.
Simply picking your battles.
|
|
|
|
|
One Dev made a snide remark, saying why was he there and earn so much when he did not even come with the architecture which he was supposed to
Well, well! What I've found being in IT for almost 30 years is that comments like this, though considered bold and edgy at the time (making you a hero among your peers!), they ultimately work against you. You will never know when the people in position above you make an offhand remark, good or bad, to the CIO or an VP about you. They might say they'll cover your @$$ when it hits, but don't count on it. Negative things will happen to you and you'll never even know they happened.
If you are tight with the Architect, troll away. If not, suppress the urge to say what you're thinking.
With that said, my Dad gave me this advice. He was an Engineer at International Harvester for 30 years. He spoke his mind many times and he knows he was held back because of it. It happens. Understand your risks.
|
|
|
|
|
I probably talk a lot more than that.
But that meeting is GOALS.
|
|
|
|
|
No real technical architect would ever say something so foolish to a group of technical personnel unless of course that architect was just a political windbag.
Technical architecture is highly overrated in such software development endeavors because there are only so many actual, concrete architecture styles to go around.
Usually such people are there to define the architectures for different types of projects that have already been proven to work. For example, if you are working for a company that tends to have restrictive deadlines for their web projects and you are working with .NET, any competent architect would always recommend the use of Standard ASP.NET over that of ASP.NET MVC due to the better capabilities of Standard ASP.NET for rapid development.
Unfortunately, the overriding issue is that so much software crap has flooded the development environments in the last 8 years that most developers no longer have the capabilities to validate one architecture or style over another. This is a result of what has come with all these new paradigms; that of using what is "cool" instead of what simply works.
For example, I learned to develop with Microsoft WPF, which I believe is a very sound technology. However, after using it for quite a while I came to realize that the capabilities it offered was really quite limited considering that such aspects of WPF were more suited to mobile development. But again, how many people really develop native, smart device application compared to web
applications that are usable on a smart device? I would say that the percentage of native mobile application development is substantially smaller.
So what is the real purpose of WPF? As good as it may be it is simply another "distraction" technology to promote new tools from Microsoft, while Windows Forms is still an excellent avenue to develop business-based desktop applications.
What I will give WPF immense credit for is the ability to develop a desktop application in the same style as a web application that is similar to Standard ASP.NET.
The result of all this is that Technical Architects are the people are supposed to already have the answers for development teams when they begin new endeavors; not come to a meeting and let developers "re-invent the wheel" wasting everyone's time and money...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
The job of a Technical Architect is to ensure the architecture provides the best value to the organization over the entire lifecycle of the product. Sometimes that means picking something off the shelf, sometimes letting developers do some of the driving, and sometimes creating something from scratch and forcing it down peoples throats.
|
|
|
|
|
He may think you guys are competent, can do your jobs, and would like to contribute to an architecture you can believe in. If you came up with a good architecture you can support sounds like had a good meeting. If you guys produced crap and he still bought in, I can see a problem. I would have walked the whiner dev out the door.
|
|
|
|
|
I did very similar project where I layout the rules and the pattern, let the people who going to develop the code design the project as they understood the requirement. I only step in to correct things if they fall outside the rules and pattern.
IMHO, good architectures will let the team come up with the design together, that way the team already have vested interest in the project. The days of throw over the wall are gone.
|
|
|
|
|
And that's why "junior" also get to do his own "estimating" (or so he thinks).
As long as "his" estimate is "less" than mine, he can run with it; and will try to make it (LOL).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
How often have you deleted a file, probably near the end of the day, only to realize as the file vanished into the void that you selected the wrong file? If you have the right tools and you act quickly, you may be able to recover it. Wouldn't it be so much better if your editor sent your files to the Recycle Bin, from which they can be recovered quickly and easily?
If you happen to be working with Visual Studio Code, you are in luck, because the file delete option on the context menu of its project tree view does just that, as shown in the picture in this short item, at https://www.linkedin.com/feed/update/urn:li:activity:6264918169501130752/.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|