|
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
|
|
|
|
|
David A. Gray wrote: as shown in the picture in this short item, at .
Can you fetch the URL from the recycle bin for us?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Visual Studio does the same thing.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Maybe as of the 2017 edition, but it didn't through 2015, which was probably soup before that feature got into Code.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Odd - Visual Studio has always sent deleted files to the Recycle Bin for me, as far back as I can remember.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
OK, so Mozilla will be going to Rust in release 54. Does this mean that the organization that had bequeathed to the world the wonder that is JavaScript (/s) is now moving on completely to Rust? Will it be that someone writing a webpage for Firefox will no longer have to deal with JavaScript and can now just work in Rust?
|
|
|
|
|
Huh... ohh
Nice title.  Tricked me, was expecting this post to be saying something very different.
Doesn't look like it's intended to be a client-side language any-time soon. It's slow to compile for starters and is intended as a systems language. Ever heard of someone writing client-side webpage logic in C or C++? Yeah, course not - me either.
|
|
|
|
|
enhzflep wrote: Ever heard of someone writing client-side webpage logic in C or C++? Yeah, course not - me either.
Once upon a time, it was fairly common; they were called ActiveX controls.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Touché, oh wow that takes me back - I'd forgotten all about those little beasts.
Cheers
|
|
|
|
|
It will soon be common again; it will be called Web Assembly.
|
|
|
|
|
Those aren't the same animal, because they are written in JScript and compiled in place in the browser. Conversely, ActiveX controls were compiled, linked, and signed before they became part of a page.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
You may be thinking of asm.js, which is just a (very) strict subset of javascript. Web Assembly, on the other hand, is exactly what you talked about: a portable binary format that is compiled on the developer's machine prior to deployment. The server will serve the portable binary to the client. No client-side compilation.
And the first language the working group is targeting isn't js, it's C/C++.
Here's some more info[^]
|
|
|
|
|
Thanks much for the clarification. Since I was under the impression that it targets applications that are extremely CPU bound, I haven't paid that much attention to WebAssembly. That, coupled with a recent news item that mentioned something about Edge being tweaked for WebAssembly led me to believe that it was intended to be compiled to something like bytecode (as are, for instance, Java and C#).
The additional information you sent clarified many things, but it didn't dispel my impression that it will require some kind of run-time support in a Web browser. Given the spotty record for things that claimed to allow you to write once, and run anywhere, I'll be watching closely, and keeping my tin foil hat handy.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I think I would have gone with the compiled vs interpreted point, but to each their own.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
