oxfordmale

Have you ever done DIY? Things like replacing a tap could be done very quickly using YouTube. Why do people still call plumbers? Because reality is never as clean-cut as YouTube videos. Sometimes, you find the connection parts have completely corroded, and you can't undo them with your standard DIY tools; other times, you discover you have odd-sized connections (metrics versus non-metrics and vice versa). The real skill of a plumber is to be able to handle real-life problems.

It is the same for coding. Yes, you can ask it to generate basic code, and it will work. But my job as a software engineer isn't to write code. It is to deal with messy humans. Sure, ChatGPT can write an app that does three things. Does it work reliably on all different mobile phone devices? And do you only need three things, or do you want 16? Most clients know precisely what they want; they can't express it accurately in words in a single iteration. When you have delivered those three things, they will often ask for more. They will often ask for a hexagon-shaped room after you have built them a perfect circular-based one and then complain heavily if you quote it will take several weeks to refactor.

>> ACID compliance available as a paid addon

Lol

>> Indexes available as a paid addon ($100/index/mo)

Even more lol

>> Employee pinky promise to not look at customer data to retaliate over a personal grievance

Our Infosec team will love this. Pinky promises can just replace the need for NDAs

In most cases brute forcing a solution, O(N^2) vs O (N log N) is perfectly fine. Simply, because you dont know if this particular feature is going to survive, and if it doesn't there is really no point in premature optimisation.

And yes, I can practice for leet code interviews, but so can unskilled candidates. Beyond that have my current job, and my own life to deal with. So if I can apply for a job that doesn't require this type of interview, I will apply for those instead.

Leet code interviews also completely misunderstand the role of a software engineer. My job is to translate fuzzy business requirements into code, prioritising the must haves over the nice to haves. This allows me to deliver a solution on time and budget. If the product is a success, I can then prioritise refactoring some of the performance bottlenecks. It is almost never about writing optimally performant code.

Finally, with LLM, once the code has been defined, it is super easy to ask such tools to refactor the code to be more optimal. The hard part is actually writing something that meet the needs of the business.

With humans, it is often easy to establish who hallucinates and who doesn't. We can all identify a snake oil sales pitch. However, with LLM, it can often be a lot harder.

Let's take an example. I studied physics and can likely answer most questions on nuclear physics. However, as it is a while back, my answers will not sound as smooth, and I may have to correct myself a few times.

If you ask ChatGPT the same questions, it will come up with elegant, convincing answers. As a layman, you will likely prefer what ChatGPT comes up with, as it is answers are eloquent. Of course, until you build a nuclear reactor using ChatGPT knowledge. Once the fuel rods become critical and start making its way through the earth's crust, you may realise you should have relied on my stumbling answers instead.

Product Managers are only as great as the last new shiny product feature they deliver. This is a systematic problem for companies. Product Teams rarely prioritise fixing technical debt that is actually resulting in significant operational overhead. They prefer to focus on yet another shiny feature, as it is much easier to market.

"We need to spend some time fixing technical debt for the last product feature we rushed to market, as it generates too many support tickets."

versus

"We delivered dark mode. Shiny!"

This is Google. You need a major feature to get noticed and promoted. This feature was almost certainly shipped to ensure a pay rise/promotion for both the manager who delivered it and the manager who approved it. This was likely different in Google's early history. Unfortunately, this is how FAANGs and other large companies operate. You can only get promoted if you deliver something that convinces other managers in the company you deserve that promotion.

The current generation of ChatGPT hallucinates far more systematically than that. The problem is that it can regurgitate what the random dudes from local accelerators have written in their blog posts. We all know blog posts are often a sales pitch and don't include useful advice, because you can charge for the useful advice you give.

Just go tell your CEO you are going to rewrite all the C++ at your company into Rust, taking months of Engineering effort, and deliver the exact same functionality at the end of it.

A refactor needs to be part of a strategic initiative. If security is paramount to an organisation, a refactor to Rust can be worth it. Doing new projects in Rust can also be a valid decision.

Old building decay over time. A lot of COBOL still runs fine decades later.

Anyone involved in a major refactor knows it is a minefield. It should only be done as part of a strategic upgrade, not because Rust is "better" than C++.

There is simply no good economical reasons to rewrite the worlds C++ codebase in Rust. It might be more elegant, but there is no return on investment.

This sounds like a snake oil sales pitch

The real problem is that genuine questions get dupe hammers.

Yes this was the right solution in the Python stone age version, but no longer the right solution in the current one.

Of course I can give an alternative answer on an old question, but it will appear very low on the page and will get missed by regular users.

At work there tend to be other inefficiencies. A lot of "spontaneous collaboration" that people claim happens in the office is people talking to pretty/handsome people in other departments, without necessarily adding to the bottom line.

In person collaboration is definitely worth it, but this needs to be planned. It doesn't happen automagically if you are being forced to sit at a desk.

I can see why middle management's hates it thought. You can no longer tap on someone shoulder and pester them in prioritising your work above others. You need to make a business case rather than bullying a poor Engineer.

I use them everyday. They are built into the standard Python libraries and SQL databases I use :-)

Unless you work at the cutting edge, developing new database engines or cutting edge algorithms, you rare use data algorithms. My day to day challenges are not the algorithms but understanding requirements from humans.

Growing and adapting are two different concepts.

Adapting is necessary for any company to survive, growing not necessarily.

Beyond keep up with inflation and cost increases, there is no technical need for a large firm to keep on growing. There are many midsize companies that have a steady revenue and are happy with it.

I am not recommending Looker either, but data extract stored on the server? That is a last-century solution. We often hit data limits in Tableau online as colleagues get overzealous.

Beyond that, it is also a major GDPR headache in Europe. If someone uses their personal account, with elevated access, you suddenly have a data extract on the Tableau Online server that contains personal data, with no way to enforce retention periods.

I hate Tableau with a passion. The main bugbear is that viewers can't see the SQL code the dashboards execute. I am no fan of Looker, but the "Explore here" allows other users to see the SQL and tweak it if needed. Most intermediate data stakeholders are confident enough to modify the where clause to suit their custom needs, allowing them to self-serve.

The licensing costs are prohibitive, too. It is almost unaffordable to share Tableau dashboards with your customers and, instead, have to send them static PDFs of your dashboard.

Beyond that, the Tableau infrastructure feels like something from the last century. Data is cached on the server using data extracts rather than following a more modern caching infrastructure.

This is for a performance issue and the Laravel code base is straightforward to map to SQL. It is to get a rough idea of the joins and the filters to see if there is potentially an index missing.

This is low hanging fruit. ChatGPT can do this, and also easy to verify it got it right.

I am a Data Engineer. I can spin up the service locally, but it would probably take me half a day to install the right versions etc and change the log level. The code is there, ChatGPT does a good enough job at it, or at least did. It is super easy to verify it did a decent job at it.

I am a Data Engineer and it would take me ages to spin up the service with the right log level to grab the query. It is much easier to grab it from the codebase. I used to do this manually from time to time, now I use ChatGPT.

A/B testing is valuable to optimise an existing process once the low-hanging fruit has been tackled, but it should also be discontinued when the return on investment becomes negligible. Because of organisational momentum, this rarely happens, as a team would make themselves redundant. This can result in A/B testing noise.

Data also provides valuable insight in a negative manner. If your conversion rate is abysmal, the data tells you to get out of your cubicle and start talking with real customers to find out what the data isn't telling you. It is still a data-driven decision. It is just a negative one.

However, in the end, data isn't going to find your next billionaire dollar opportunity. You need to find a gap in the market that no one has tackled before, and of course there is no data for, otherwise someone else would have jumped on it.

I have also seen ChatGPT going berserk yesterday, but in a different way. I have successfully used ChatGPT to convert an ORM query into an actual SQL query for performance trouble shooting. It mostly worked until yesterday when it start outputting garbage table names that weren't even present in the code.

ChatGPT seemed to think the code is literature and was trying to write the sequel to it. The code style matches the original one so it took some head scratching to find out why those tables didn't exist.

I have build many successful systems without ever using a GUID. However, at a certain scale they become very handy, and it then it definitely helps you can also sort them.

UUID7 offers several key advantages:

  - sortable by insertion
  - less vulnerable to sequence prediction attack
  - allows partitioning of tables in the future

Sequence prediction attack is a problem when you want to use identifiers in a public API. For example, a user or competitor can iterate through your product catalogue by incrementing the key. Sorting by inserting is a common use case as well. You can achieve this with an auto-incrementing primary key, however, this will create issues when you need to partition the table. Of course, you may never need this functionality, but there is a reason UUID7 have been added, as they are very useful in certain scenarios.

It is mostly herd mentality. A lot of senior management are clueless and will copy what the big players are doing. Like lemmings, they will all crash off the same cliff together.

Since it is an employers market right now, it is something companies can afford. However, I suspect they will be complaining in a few years they can't get the talent.

Just a few links to companies that advertise to clean up your company profile on Wikipedia.

https://www.wikiexpertsinc.com/get-free-wikipedia-consultanc...

https://www.legalmorning.com/cleaning-up-a-company-wikipedia...

Yes, I am not necessarily disagreeing with this approach. The problem is the imbalance. A PR company can buy a news article, link it and update a Wikipedia page. It means the balance is in favour of big corporations and wealthy individuals.

The problem is that PR companies can push out whatever they want, where as an ordinary individual with personal knowledge of a topic, can't. It means many Wiki articles on person or companies, are often glorified advertisements, rather than encyclopedic entries.

Wikipedia is great for non political, non-controversial topics, such as sciences. I wouldn't trust it on active politicians or other figures of public interest.

One major problem is that you need to submit references to back up any claim. PR companies can easily buy an article in a fringe news site and them modify Wikipedia with a reference to that article. It is almost impossible to roll back.

I once tried to update a company page to state they were going through redundancies. I was personally affected by this, and had internal emails to back this up. However, lacking a public reference it was rolled back.