In case y’all are interested, this is the article that came out of loads of input. https://www.functionize.com/blog/oh-the-things-we-had-to-do-to-debug-software/
My name is on the spine of about a dozen books.
One of them, one, paid out the advance.
Nonetheless, I’m not sorry I did it. The “street cred” from writing a book for a name publisher opens doors as if by magic. I’ve written many thousands of articles, but “Author of Book Name” makes peoples’ eyes light up. It’s not logical, but it’s true.
Funny that after the title and initial comparison with review sites, the word ‘review’ never occurs again. Has nobody ever tried to create a site where people write reviews of packages they’ve used?
Hey, I published the article – with a callout to your input. https://www.functionize.com/blog/6-ways-to-improve-your-debugging-skills/
Maybe it sounded like a good idea in 2019?
Also I know so many people that got on the Swift bandwagon and thought it was the best possible hammer for all possible nail-like objects. (And I’ve seen that theme for so long that I remember when Turbo Pascal was the best language for everything,)
I like Swift. It’s got a lot of really good design baked in, but I can’t honestly imagine why anyone would choose it over anything else unless Mac or IOS are primary targets.
As I mentioned above, I don’t understand why anyone would choose Swift who isn’t planning on developing a native IOS or MacOS application.
Ian (author) mentioned that he nominated Swift because of it’s TensorFlow bindings. Fits @notagoodidea’s observation neatly.
I’m aiming to write an article to help developers, devops, and testers determine if a given vendor’s application meets the company’s needs. The only assumption I’m making is that the software is expensive; if it’s cheap, the easy answer is, “Buy a copy for a small team and see what they think.
Isn’t that what the proof of concept license is for?
If the software costs, say, $400, it’s easy enough to buy a copy and give it to one team. Ask them to evaluate it and tell everyone else if it’s worth the money. If it seems good, get another 10 copies for different teams. If they all give a thumbs-up, buy a site license. Easy enough.
If it’s $40,000 – or $400,000 – that doesn’t work so well.
And even so, the small team needs to figure out what works for everyone, not just the single team. If that team happens to be writing an e-commerce application, they can only say if it’s helpful for e-commerce projects; it doesn’t tell anyone if it’s useful for backend applications.
Thus it’s a good idea to have some kind of guidelines for “How do you do this well?” As with anything else, it’s usually wise to learn from someone else’s mistakes.
Right – my point is that your first choice should be negotiating a proof of concept license that lets you try out the experiment you want to do, rather than shoehorning the experiment into what happened to be negotiated.
Right. But the article has to start somewhere – which is defining the experiment and how you aim to go about it. I’m taking it as a given that you can negotiate a license that lets you do that.
Thanks for sharing. I’m just wondering are there still companies without continuous integration? Don’t get met wrong I get into discussions with our infrastructure team quite a bit about how the CI should look like but no one questions that there should be a CI.
There were plenty of government agencies still using COBOL, so you should never underestimate the slowness of tech adoption in some shops.
I’ve been really sick for most of this past week, possibly with COVID-19, so if I actually get out of bed…
x.c, which is a worthwhile improvement, but makes maintaining a fork hard. I’m making progress, though, albeit none of it’s committed yet.
If I don’t get out of bed…
I remember seeing lake on unixporn maybe like a week ago, and thought it looked super cool! definitely going to be keeping an eye on that.
(ps your website is really nice looking)
I think this would be a lot stronger if you went into detail on each “thing” and its consequences. Like what is the insight we get from “Testing is never complete”?
I agree that it would be, but I only asked the “what was it…” and not everyone gave me, “…because.”
I wish there was more to this story. This blog post is based on a report titled “2020 State of Software Engineers” published by the data science team at Hired. The report is based on analysis of hiring on their platform as well as a survey of 1,600 users of their platform. Without seeing either the underlying data or the questionnaire, it’s hard to interpret these results. I want to know more about the pre existing stereotype. Is it a person who stays up late drinking coffee and listening to heavy metal?
I’m rather put off by the whole thing, myself. Stereotypes are inherently disrespectful of human diversity, and perpetuating them in a professional context is only harmful to individuals and to the profession. It saddens me to see IEEE promoting this shallow and unscientific ‘hot take’.
The data collected by such a study could indeed be useful to those looking to hire or retain engineering talent, but we’d need to see the questions, the distributions of answers, and as much context as possible about how it was collected. Then, we should compare findings across similar studies from different researchers and populations and times. That’s how real social science is done.
I don’t know, maybe the blog post is just an ad for the actual data set? It’s still in poor taste.
Isn’t the point of this that the stereotypes aren’t accurate? To me, it’s less “create a new stereotype” than “recognize that your expectations aren’t accurate.”
I hope that we could keep the vim tag because I’m not interested by other editors (vim is sufficiently complex to keep me occupied for at least a whole life and I guess it is similar with emacs).
Vim and emacs are more platforms than simple editors. There’s always more to be discovered. I fear that an “editor” tag will quickly become a mess with everything from the last IDE release from Microsoft to the anecdote about using Notepad in 1998.
But as long as we keep vim, I’m happy.
There’s precedent for general and more specific tags, e.g.
osdev, so I would imagine an
editorstag would live alongside more specific tags without too much of an issue.
Can we have one for edlin? ;-)