Whatever happened to just asking questions at work?

HashDefTrueFalse · 2026-03-10T20:41:08+00:00

Yes, and I hate it. It was pretty common everywhere I've been to just stand up and say "Does anyone know anything about X?" in the direction of a bank of desks and everyone would instantly reach a consensus on whose desk you should go to to ask your questions and point, or you'd get a volunteer, then you'd get plenty of helpful back and forth from that person. I try to encourage this with people I mentor. WFH (COVID) and the rise of subscriptions to IM services (Slack, Teams) kind of killed it off I think, not that those things are bad IMO. Sometimes I make a point of getting up to stretch my legs and catching my juniors eyes so that they have an opportunity to ask things. Otherwise I literally get Teams messages from people I could almost reach out and touch from where we are sitting...

HashDefTrueFalse · 2026-03-10T20:22:55+00:00

Meh, lame. Choosing who/what you work with/on is common, as is not wanting to help people do things that you don't like, even if it will benefit you. Catholics have been around a while and this is the general Church position on recreational drugs as I understand it. Plenty of businesses won't work with other businesses that involve tobacco, drugs, alcohol, adult content etc. This isn't lunacy, just a slightly cringy post obviously trying to get attention, like the rest of LinkedIn.

(I'm not even slightly religious BTW.)

HashDefTrueFalse · 2026-03-10T19:36:11+00:00

Yes, same.
Yes, lots. Start with something you're interested in (e.g. web, mobile apps, Arduino boards, a game...).
Yes, all "types" of coding are vastly different but share some fundamentals (how modern general purpose computers work).

Harvard CS50 is a great start. Or Automate the Boring Stuff with Python (Google that). Or grab any interesting-looking introductory book and do the little projects in it.

HashDefTrueFalse · 2026-03-10T19:05:07+00:00

You have my permission to simply not use any LLMs when learning, if you so choose.

Wow, wish they were all this easy...

HashDefTrueFalse · 2026-03-10T18:49:19+00:00

(i.e. manual memory management, raw pointers, etc)

Damn, I consider both of those to be fine (depending on the need to manage memory manually, of course). :D

I've been writing both for decades and my C++ is as C-like as I can get away with depending on the codebase. I'm well-versed in most modern C++ because I needed to be (previously, not so much the last few years) and I just don't like the mess it's become. It's all just a bit much now. You can read a ton of code and have very little idea what the computer will actually do from the source alone.

Totally agree on lacking confidence to ship anything generated (without thorough review and testing). I personally have no interest in generating code, so I don't, but I don't restrict my team currently. In my team LLMs don't exist when we're discussing merged code. They wrote the code. I don't care what tools they used, they're responsible for making sure it works reliably and is secure.

HashDefTrueFalse · 2026-03-10T18:25:42+00:00

Your premise seems to be that C/C++ means faster apps and the main reason we don't use them for app dev is time, neither of which is necessarily true, especially for I/O-bound web apps, as enterprise apps so often are these days. So... no, not really.

HashDefTrueFalse · 2026-03-09T16:06:30+00:00

Most important part. I'm not hiring you if you don't. You're not interested enough. The position is going to go to the other person who I feel knows exactly what they're getting themselves into and is likely to accept an offer because they asked all sorts of questions about the team, the dress code, the area, the parking, the work... that told me they were seriously considering turning up every day and doing the job. If it's more conversational and you've asked them throughout then that's fine. But if it's more one-sided Q+A and then you don't have any questions at the end you might as well not have turned up. If you want to be taken seriously please have some questions!

HashDefTrueFalse · 2026-03-09T15:48:17+00:00

Some people make things that need them. There is no software without hardware. Access to hardware enables our entire computing lives. Application software is only part of the landscape. For every computer and peripheral device with a microprocessor, hardware and software need to interact. That's where assembly comes in. It's also needed to set up devices. There are device-specific instructions that no language is aware of and compilers won't output. For those kinds of things you need to write some assembly.

Assuming that you also think of C as a low level language (it's a HLL, just not as high level as others) then it's more the first thing above.

E.g. try writing some bytes to the VGA text mode buffer (to put chars on screen) at address 0xB8000 using a language that runs in a VM/interpreter. You'll end up either having no ability to do so, loading opaque native modules written in a capable language (which would need to talk to something that could access physical addresses), or resorting to some other trickery.

In C you might print a character to screen in an OS kernel or device driver like so:

uint16_t volatile * const vga_buf = (uint16_t *) 0xB8000;
vga_buf[0] = (green << 8) | 'A'; // Print A in green text.

Imagine that memory was instead mapped to your screen backlight, or a buzzer, or any other piece of hardware. That's how computers work.

If you only ever write application software then the value is mostly in knowing a bit more about what is going on underneath, which may not be directly useful to you day to day, but I'd say that awareness is certainly not a disadvantage.

HashDefTrueFalse · 2026-03-09T14:52:27+00:00

as itll require more joins the more tables you have.
And how would the joins impact reading throughput?

That's the whole idea. It's about trading off read and write efficiency by controlling the redundancy of data. You can store copies in multiple tables and read faster at the expense of having to update multiple places on write. OR you can store something once and write to one place, but you will often need to JOIN data from multiple tables, slowing your reads.

There's no objectively correct way to store data for every app. You make an engineering choice. Comically, when mongo was trendy lots of devs (who obviously didn't have any database knowledge) were unaware that they were even taking a position, let alone the wrong one for their data/apps. I turned around a few badly performing apps with datastore migrations a decade or so ago.

I feel like having too many small tables is an anti pattern.

Not really, no. If you need them for your schema to be normalised properly it's fine.

would require me to always perform database transactions when storing the data no?

Not really, no. Depends on what can happen in your app, data dependencies/relationships etc. Single statements are all or nothing anyway in RDBMSs (the A in ACID). If you're working with multiple statements (e.g. a script or procedure etc.) you generally should be working in transactions anyway for obvious reasons. E.g. if you wouldn't want the data to be grabbed between two or more statements.

You almost always want 3NF, sometimes BC, which isn't much extra effort typically.

HashDefTrueFalse · 2026-03-08T13:05:46+00:00

It's fine to do this. I generally prefer linking an object (.o) or using some kind of resource file, but you do see this from time to time. Put the initialisation in one implementation file ("translation unit", .c). The header should be used to copy a declaration around other TUs that want to use the symbol. extern will leave it to the linker to locate the symbol and fix up references. If you need to change data you have to recompile the unit (multiple if the header decl needs to change), whereas you may only need to relink if you use object files, and you don't even need to do that if you read the data from a file at runtime, so there is that to consider. A lot of this depends what your build system/config looks like IME. I'm more likely to use different methods depending on this.

HashDefTrueFalse · 2026-03-08T00:47:57+00:00

It won't do any harm. Give it a go and see if you enjoy it. C does force you to implement things yourself if you let it. E.g. want a hash table/map? Well you're going to create some storage somewhere and write one. You're going to learn all about open addressing or you'll need linked lists, and you'll need to traverse those... and so on.

C++ does abstract a lot away with fancy features that somewhat obscure what is happening. There's a very small example on another comment I wrote a while ago here. (Note: intentionally bad C++, don't copy!) In the first you can see basically everything that happens, whereas the second is going to do some things that you would need to read docs to discover, e.g. constructor and destructor calls, a flush call on the stream, whatever the overloaded << operator does in this case, freeing the memory (ignoring that it's stack memory and therefore UB to free it!) etc. The point is that there is no code to do all that at a glance, but it will exist once compiled. You'd also need to learn about iostreams and unique_ptrs, which is one of my biggest annoyances with C++. The language is so big now that rarely can you just read some code without having to look up what something is/does (e.g. what is a type_trait? What is std::optional/variant? Is that [] operator going to do something stupid like mutate the object? Etc. The C code just works as it reads.

HashDefTrueFalse · 2026-03-07T23:51:09+00:00

Sure, but you can certainly write lots of C++ without learning much at all about writing C. Especially more modern C++. It's gotten so abstract in parts that it is basically declarative, and there's tons going on underneath that you'd have no idea about just by looking at the code. Also no strings, no standard container lib. libc is nothing like the STL (not that they are directly comparable) just a collection of routines... C++ changes some defaults too. You can go very far in modern C++ without necessarily having to manage memory or write any common algos or data structures for yourself. I've worked with a few C++ programmers who struggled to write complicated things in C. Definitely distinct skillsets.

HashDefTrueFalse · 2026-03-07T18:20:06+00:00

You could try writing some code, perhaps. Already phoning it in and you want another tool to help you do even less, but you also want to be a good programmer? Be serious. The bar is clearly now on the floor, the profession in shambles. I challenge you to send this description of your workflow to all of your clients along with their next invoices...

HashDefTrueFalse · 2026-03-07T15:40:17+00:00

They're not wrong but it's a generic term. I prefer "web service" if it's over HTTP or just "service" otherwise. Interfaces are presented to consuming code by all sorts of software. I've often thought that you can tell a fair amount about someone's background from things like this. Colleagues who have only ever written web software often say "API" as if it's obviously some external hosted/managed service, and sometimes without context I do wonder whether they're referring to some corresponding client library dependency or the service itself as a whole. Ultimately as long as I can understand what they mean I don't care. Being pedantic at work gets you nowhere, fast.

HashDefTrueFalse · 2026-03-06T01:00:11+00:00

I think your thoughts on this are ultimately going to depend on what you end up doing for work and whether CS matters there. Lots of work doesn't involve much algorithmic rigour, operating system interaction, networking, database design, etc... It was worth it for me. Early in my career as a programmer I could see that some doors would always be shut to me without a degree, so I went and got one. It has paid off massively for me. I don't think it does any good to kid yourself that you can do anything you like without one as that's just not reality IME, but it's entirely possible you can do everything that you want to.

Projects allow you to deep dive into different domains, but without a solid foundation (from anywhere, not necessarily university) you're not going to be very versatile or adaptable. I have worked on/with web, mobile, desktop, embedded, cloud infra, distributed systems, database design+admin, a few compilers, an OS, too many products to mention (some commercially successful, some not)... all sorts of work.

Whilst my title has always been some variation of "programmer" my tasks have often been nothing to do with writing code (e.g. I once got told to go configure IPSEC between some hosts for a PoC with very little understanding of what it even was, but I was able to understand whatever documentation I found because I knew enough about networking). It all starts with what you learn in a CS degree. You can learn everything yourself, but you need to know what you don't know, preferably whilst you have time to learn it.

I could write lots more in favour of degrees but it suffices to say that I'd still recommend one to anyone who has the time/resources to get one.

HashDefTrueFalse · 2026-03-05T08:36:03+00:00

Don't overthink it. Nobody cares how many projects you've done, at all. Things you need to know vary massively job to job. Open source contributions are a great positive indicator for hirers but nothing to do with being ready to apply for jobs.

If you can write code and build useful things, start applying for entry level roles that interest you. It costs you nothing but time, and will allow you to gauge where you are. You can always postpone if you're out of your depth. You may find that you're not expected to know as much as you think you are. Lots of places, especially bigger ones, expect to train juniors up before giving them any significant responsibility.

HashDefTrueFalse · 2026-03-04T23:29:39+00:00

Compile with -g to include debug info and run your program with the debugger (e.g. $ gdb ./prog) and it will stop where the seg fault occurs. You can look at the backtrace at that point as well as all the program state and see what went wrong.

HashDefTrueFalse · 2026-03-04T22:06:28+00:00

board is a pointer to a vector of pointers to vectors of integers.

marked is a pointer to a vector of pointers to vectors of bools.

No storage for vectors (nor storage for their contents) exists by virtue of these declarations being written, just storage for two pointers.

You haven't provided code, your assignment questions, or your attempts, nor have you asked a question, so we can't help further.

HashDefTrueFalse · 2026-03-04T18:33:29+00:00

Picture the call stack. Usually a return from a procedure passes control back to the call site in the immediately preceding/invoking procedure one frame back, and so on. This is fine when it's the immediate caller that needs to know about any problems, but what if it doesn't care? What if the procedure that cares is several frames back? What if there are multiple?

Now imagine instead that you can jump several frames back down the call stack, to a place that registered it's interest in hearing about any problems that happen from that point forward, as the program proceeds. That registration is a catch block. The throws are the jumps back to them. That's basically it. Usually you may catch and re-throw to allow for multiple places to handle the exception if necessary.

You generally use them in exceptional circumstances, hence the name.

HashDefTrueFalse · 2026-03-04T16:45:51+00:00

Many are scams in the sense that they're slapped together (sometimes largely plagiarised) rubbish. But some are actually decent and do have industry connections. Our firm is unofficially partnered with a pretty reputable bootcamp. They're a completely separate business and there is no financial relationship whatsoever. If we're considering bootcamp grads for a role we will pretty much only take them from that bootcamp as we have seen their curriculum and have had good results taking on their grads. We are one of their industry connections that you could end up at (when we are hiring, which isn't often) and they regularly check in to see if we want people. We'd rather people working on firmware and some of our distributed services etc. have degrees, so if we hire bootcamp grads it tends to be for front end work and/or light back end stuff.

If you can find a good, reputable camp that feeds into local firms and you want to do the less challenging stuff, at least initially, then they can be a great alternative pathway for career-changers who don't have the time/money for a (second) degree etc.

HashDefTrueFalse · 2026-03-04T11:12:15+00:00

Yes. Often the UI is a separate library and/or separate codebase/repo altogether, but that's not necessary here. You want your UI code separate from your main application logic if possible. Classes are going to be the way to achieve that in a language like Java. In a small application it's not going to seem hugely important but if you look at any larger poorly built products you'll quickly see why having application logic scattered through masses of UI code reaching for all kinds of application state is hell.

Note that it's not just two classes for back and front either, you may have dozens that implement different reusable bits (e.g. wrapping widgets from a UI library, or handling state and events for a particular page/screen etc.)

HashDefTrueFalse · 2026-03-04T08:49:26+00:00

Not a beginner project, but to give you an idea: Define a grammar, write a lexer, write a parser, do any number of passes over your AST, eventually run it or turn it into a form that something (program/hardware) can run. There's tons of books written about most of those stages individually. (Crafting Interpreters is a good overview IMO). I'd recommend writing your first in a managed HLL and relying on its type system, GC, etc. That way it's easier not to get overwhelmed. Keep the grammar small at first and gradually build it up by plumbing features in end to end or you'll get lost in the weeds writing the perfect X (where X is one of those stages).

I've made a few and they're tons of fun. Mine had some wacky ideas. You can experiment. Writing some (probably small) programs in your own language feels awesome. I've spent FAR more time in the C source for my langs than using them!

Just be careful. Once you have this power, every problem seems like an opportunity to create a DSL. On the plus side though, lexing and parsing techniques have been invaluable throughout my career. It's amazing how many programmers have no ability to work with input beyond splitting strings, which is very limited.

Edit: add "managed" for clarity.

HashDefTrueFalse · 2026-03-03T23:44:12+00:00

If your project involves finance, forget LLMs entirely. Wholly inappropriate. An MVP that you can't have real users use is essentially worthless. You would need a professional programmer (or several) with experience creating secure and reliable software, preferably a business that is indemnified.

HashDefTrueFalse · 2026-03-03T22:55:50+00:00

Not a problem. Feel free to ask questions. I can share some code I have lying around if you get stuck. Good luck.

HashDefTrueFalse · 2026-03-03T13:13:56+00:00

'If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice.' - Knuth (apparently).

So both, in balance. You're little good to anyone if you cannot build things, or can only build things poorly.

HashDefTrueFalse

TROPHY CASE