kovac

I agree. I find it utterly disrespectful for all the engineers who are working their asses off to save the free internet when someone tells me to stay off the internet if I don't want to use a Google service. It's that bad.

Almost everyone, I've spoken to about these (including software engineers), know they are being tracked and they don't care. Actually, you know what, not almost everyone, everyone I've spoken to about this.

I've got the reply "if you don't like it, stay off the internet". Well.

How can a library providing only sync functions a good thing? Lots of IO is inherently async and it makes little sense for a library developer to go out of his way to make it synchronous only for the callers to make things asynchronous again. If something is async, it's async. You deal with that.

Also, I don't see why one would even consider using a framework if squeezing out every bit of performance from your hardware is that important. I can't imagine writing a Web app without some framework in the interest of time it takes to develop. Then writing a hundred of the same stuff again? You just have to ensure you don't use a bloated framework which is akin to not choosing a bloated library. Unless you are working on a device layer, it's not our job to spread things over the hardware. Unless you have direct access to memory, you can't do this anyway with most of the languages designed to develop apps. I think the primary goal of an app developer is to implement the business logic correctly and securely in a reasonable time. I agree with the OP that libraries should be preferred but I don't see a problem especially with performance in the domains frameworks are used.

It's possible that the contract with these employees requires 3 month notice period both ways. So, an immediate dismissal would require them to pay it in compensation (guess this would also depend on the legislation). Regarding the insurance, usually its already bought for a year or so, so they possibly let it run as there's no point in revoking it without getting a refund.

If the 3-month notice is true and the compensation comes with that, then its still cheaper to let go now than in 3 months as there will be other costs like bonuses, expense claims for phone bills etc, other mandatory govt insurance schemes in some countries, more leave accrued. I'm not too convinced that it was all a nice gesture.

Really good list, thanks for sharing.

What's strange is I can also give you examples of how testing code bugs that had been there for more than 3 years (security related mind you) and a company whose release branch didn't compile on my day one because a guy who doesn't believe in any software development process and committed directly to the release branch.

I don't mean, dogmatically follow unit tests (actually my statement wasn't predicated on unit tests). If you have a better approach that can validate the software is correct then I'm all ears. If you have a better collaboration tool than git, I'd be happy to try it. With all due respect, what I can't do is take your word for it that you can build software that works (covers all functional and non functional specs), and they continue to work as more code is added, and is worked on by more than one or two developers, and that you can continue to validate and roll out more software over the years even when the original developers aren't around. It's difficult, costly. It can work, it's just not the best way. The industry will evolve and come up with better tools and processes than we have today as we did before yesterday. Only thing I took from the couple examples you gave is that you've had the misfortune of working in some terrible teams. Though I still don't see how you'd be better off without the rest of the usual practices we have today. The guys who couldn't code the tests, I can't imagine them building a non trivial software well either. I'm not defending any one process. I just don't agree that we don't need any process, and that we should just write code that (seems to) works.

That sounds complicated. Though I'm not sure if this is a valid example to counter my view. I can't comment on the exact situation you went through. It could be that that complexity was a side effect of having to solve far more complex and frequent issues more easily as opposed to doing simpler and rarer things more easily (unless of course changing button colours is a frequent modification). It's also possible that the design was simply bad.

This doesn't mean that you were going to better off without git workflows, code reviews, tests. My experience has been the opposite. It's exactly where there's no good technical leads/technical discussions/code reviews I have seen this kind of mess. Each person goes on and do their own thing with no clear direction or architecture.

At the end of the day, for me, to stay sane in the face of this kind of nonsense(as in bad engineers - unfortunately there are those even at senior positions), so what if the button that could have taken a few minutes to change now takes 6 days if we are paid to do it? As a responsible engineer, you point out the issue perhaps with a proposal for improvement. If they listen, good. If they don't, fuck it. On the other hand, if all I end up doing is changing colors of buttons regularly, each taking a week, then for the sake of my career, just say no and move on - unless of course if the pay is so good that it makes sense to spend a couple years doing it - people have to do far more shitty jobs for less. And spend some of the free time to code like a cowboy :)

I don't agree with this view. I agree with the original commentor's comment. I do this myself outside of work just to enjoy building something without the responsibility of having to maintain it with 20 other engineers for two more decades.

However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.

Thanks for the advice and i actually wxperience that diminiahing return you mentioned. I initially learnt programming with c++, so mostly picked it up again purely for nostalgic reasons to see where the language is now. It's become unmanageably large now! Where i live there isnt much work in C++, so job prospects are low for C++.

Im thinking of may be Rust or Go right now for more pragmatic reasons. Thank you for sharing your opinion.

Interesting you said that. Recently, I started doing some work in C++ again to stay up to date with what's going on in the C++ world. Do you really feel it's not worth it? I'm thinking about something new to do, and C++ is what I picked. I started implementing a TUI email client.

The build time of C++ can be really long. I noticed it too.

Don't beat yourself up for that. I tried Go sometime back (year or so may be) and found it an awkward language. It probably has its own design philisophy may be that I missed.

Things like lack of generics and type system makes you repeat things quite a lot (e. g. It was pretty impossible to write a true ORM or a DI system in go). I found the interface system quite awkward in that types implicitly implement an interface if they have the same method signature was weird to me. I think method overloading wasn't supported either, if I remember correctly.

I think people who loved Go initially probably came from C. It feels a lot like C with better standard library, memory safety and fast compile times. I like Go for the same reasons actually. But until there's at least some way to write generic code, it's an awkward language to anyone coming from more expressive languages. I program in C# mostly which is an extremely expressive language with classes, interfaces, generics, expression trees, linq, delegates (akin to function pointers). Go is far behind other languages for application development, my two cents. But for systems programmers used to C which is a very small language, Go must be like a transition to paradise :)

I see, thanks for the clarification and it makes sense.

Uh, have you used SignalR over web sockets? From a performance point of view its going to be much better than Http based polling. Which should make a different when we are talking about updating the UI.

This is a good point but I'm not going to be too quick to comment on those developers. Because they may be working on paid products and they contribute to the upstream project when they find certain features missing.

I like opensource, I myself am a Linux user. I just like a world where perhaps individual devs can build nifty useful software that we pay a small fee for and use. This way the small guys can benefit. Unfortunately, the current state of OSS (which has changes since the early days) are concentrating more power in the hands of a few organizations.

Take Sublime Text for example. I like it that an engineer builds something useful, ask a one time fee for it and we pay something really affordable for it (while there was also a free version available). This way, talented software engineers could actually make a decent living without everyone has to build crappy software for an advert-based economy. So, IMHO, opensourcing the software is an act of grace and would be at the discretion of those engineers. To expect everything to be FOSS or perhaps even demand that, I find is detrimental for individual software engineers/small players.

Considering the quality and capabilities of Qt, I really think they should just sell commercial licences. Considering the fact that the engineers at Qt need to pay to eat and pay their bills just like me, I find it absurd to expect something like this for free. In that sense, I think the current situation is very gracious.

The most common complaint I've heard from the data science team is that there isn't enough data to work with.

I'm not fully convinced that data science with ML and more modern techniques are applicable across domains out of the box. I think there is value to be added if data scientists can specialise in domains.

If we take humans as an analogy, even with the kind of general intelligence we have, we need domain expertise to be able to have advanced intuitions and make predictions about the future. I believe this is true for data science as well.

Have you tried A allegro5? Any take on which is better? I've tried both, but I'm too much of a newbie to have a reasonable opinion. Thinking of getting back on to one of the two.

The problem with this reasoning is that the numbers will start to look a lot less practical if we consider the total number of projects Google has shut down. If we applied this reasoning each time, they'll be out of cash a lot sooner than your estimate.

I'm all for abandoning projects that makes no sense to maintain. But if this happens too often, then somewhere along the decision chain people are missing the mark on what's worth building and supporting. In Google's case, they should probably put a bit more thought into it before releasing something to the public. This situation, to me, is a sign of overconfidence among Google workers about their abilities. In humbler places, they do side projects too but before they start them there's a lot of discussion about the purpose of the project beyond the code and the value it brings. When I saw the list of projects Google had killed, most of those projects looked plain boring to work on and seemed like undergraduate projects. Then again, may be it's it's own strategy to build as many stuff as you can quickly hoping some of them might take off.

Even if you can't afford to buy those, I'm sure you could talk to your manager/company and ask to borrow the ones you use in the office till you are able to go back to work. In a situation like this, I think they'll understand.

Judging by the feature requests in the open issues, I'd say we are witnessing the inception of the text editor of the century.

I apologise for that. Actually that wasn't my intention. I meant to type "May be it doesn't require too much care" but I was typing on a mobile and I missed it.

I do not look down on any programming language. What I meant there was that php is often used for Web applications. Not server side performant critical or security critical components or systems programming. There's also a practical reality that some kind of coding doesn't require too much regulation on how we need to write code. I realised that bit came out wrong but I couldn't edit it.

"It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write." This. When someone does this in a hurry or because they didn't know better, it's understandable. But when someone thinks that this style of working is superior, that's a huge problem.

Not to be rude or anything but if you continue down this road productivity might be the only thing going for you and you'll soon realise you are the only one who can work with your code.

Substitute software engineering with any other engineering descipline with "I stopped worrying about best practices" and you will be able to see what's wrong with your approach. But then again, if it's php, your domain doesn't require too much care.

I've been taking a puff at the wrong time. Should have waited for the traffic to clear a bit :p

Title is just misleading, as is often the case with this kind of studies nowadays.

Nowadays surprise calls are mean someone's trying to sell something I don't need and to scam me.

I did poorly for SAT general ability test. But was at the top most percentile (I can't remember the exact number here, long time back) in the subject tests (I think I took Math and Physics). I wonder how that happened if both tests predict performance equally well.

Looking at these, I feel that browsers do way too many things than they should.

Right. If your tagline is privacy first, the defaults should be set to maximum privacy (unless if it might break sites - in which case it may be acceptable to set to a less intense config). Any features that is a compromise between privacy and convenience, should be easily enabled/disabled through the UI (not a bloody config file). If they can build a ui for everything else, I don't think it's too much to ask for a simpler switch for privacy related options.

Trying to save my passwords is particularly annoying till I disable it.

Somethings that's going to impress you down the line with C# debugging are using parallel stack views to debug multi threaded apps (without this could be significantly harder), remote debugging (sometimes you simply can't debug your application due to practical issues like may be your app interfaces with an expensive or impossible to deploy in your dev machine to debug with it), the watch feature in the debugger that allows you to debug complex linq queries and even expression trees on the fly and debugging external assemblies by attaching debuggers. VS is heavy on resources, but it delivers value unlike a gazillion of JS apps.

You've got some insight there. But what can we do if humans just like to see and interact with beautiful people and avoid the ugly? It makes things a bit bleak for me personally, but I guess people want what they want :B