Different platforms should probably be their own repo. How much code could they share?

The .NET framework looks much cleaner than whatever frankenstein-ish hodge podge of java equivalent api's you'd have to throw together to build anything meaningful, just from my novice viewpoint

this doesn't necessarily matter, and isn't how i'd recommend thinking about it. independent frontend and backend projects can (and often should) share code by means of standard npm modules. for private projects, you can use private npm modules (which are cheap) or just use private github (or other) to do the same (free, just google for tutorials).

ie, let the other relevant factors decide if the projects should be separate (logical separation, responsible teams, likely pace of change, etc) and rely on modules for code re-use.

to take an extreme example: just think about the libraries you use on virtually every project -- underscore, ramda, jquery, whatever it is for you. yet every one of your applications is not part of the underscore project...

without knowing too much about your interfaces, but if you split "modules" into multiple repos and a single issue often causes you to have to commit changes into different modules, it seems like you dependency issues and it'd be better to keep 1 repo and just document releases there

to add to this, since my comment above didn't address the original question: when you publish independent code to a separate module (whether it's public or private), you should think of that module as library code, the same way you think of other authors' modules you download from npm. it should stand on its own, and should rarely change with your application. when something changes in your application, you don't ask the author of express to make a change. you only do that when you find a bug or hit a genuinely unlikely use-case that requires a new feature.

so if your modules are changing in parallel a lot, it probably means they haven't been divided up correctly. they're overly coupled.

Is this really realistic though for a project pretty early on? I mean if I decide to change how im storing something in the database, or how I return a json field, its going to effect other projects instantly, and that kind of change is frequent in early inception.

exactly. that's not a good boundary. how you store something in the db shouldn't be affecting application objects. still, by all means begin with a single a giant project, and wait until concepts coalesce and stabilize before breaking them apart. but if that's the case, the answer to your question is not to have your sub-modules yet...

I mean I get what youre saying, it just seems really utopian to imagine in real practice.

A monolith is probably a better place to start though I guess, sigh

to be clear, i wasn't being sarcastic. a monolith is the right place to start. i was saying embrace that when it's the stage you're at. and then when things come together, refactor as needed. what's utopian about that?

No that part makes sense. Monolith is probably the correct play. Its more the concept of decoupling in such a fashion that no change affects another part of the system, especially when youre just a few devs early on in a project. Change happens all the time, its not like were at the point where we would just version the api to avoid breaking previous clients. Were at the very start

You trade OMG everything for a cohesive, environment optimized for certain ecosystems and use-cases. It is a classic omakase.

I believe there are valid criticisms against .Net that extends beyond Windows-only, though I think C# is a pretty good language.

There's a criticism article of .NET here from a few years back. Criticisms in it I agree with:

- .csproj and .sln files suck
- IIS kind of sucks (but is no longer required)
- Many of Microsoft's ideas for how applications should work are bad (WebForms was an absolute abomination top to bottom, though to be fair technology was very limited at the time, and ASP.NET MVC is out of date at best)

That's about it. All his other beefs are either general problems not really related to .NET (threading rather than an event loop has its issues for a webserver, for instance, but that's not really .NET's fault) or else I disagree with them. (The ease of use of SQL Server in VS is a problem because "All of my projects now utilize a JSON-based key/value store" and... well, at this point I start losing what his problem is?)

sure, that's how it's supposed to be at the beginning. yet even from the start pieces unlikely to change will appear. say you have some custom way of formatting dates, and you write a "fmtDate" function that both the backend and frontend use. you'll likely end up with one or more modules for utility functions like that. you shouldn't actually break it out yet, but "change happens all the time" does not imply "nothing is stable".

I think you have to be feeling real pain from the monolithic app before it makes sense to address it.

I've definitely caused myself more headaches by breaking up repos / pulling out libraries / etc. too early than the other way around (although, maybe if I'd made difference choices I'd be making the opposite complaint - hard to be objective on relatively rare decisions like this).

All very valid, my point is just early on I'd prefer to lean on not abstracting out things like shared utility functions until decisions are finalized and design is pretty set.


I do this too (obviously from the original question) but things like a react front end vs a mobile front end seem to immediately lend themselves to being a different project. Plus it's more fun to do something different when it's in your spare time, which is also an argument for me wanting to set up the whole thing

Sandi Metz concurs: “Dealing with duplication is far easier than dealing with the wrong abstraction”. It's good advice, unless you use it to excuse never finding the right abstractions.

There was an interesting Ted talk I listened to long ago about this. I'll see if I can find it. It had an anecdotal story about chicken gender pickers and other things where we get better by doing.

A lot of people get stuck from beginner to expert on the intermediate stage due to what you're mentioning here.

I remember that talk. The point of interest was that the gender pickers couldn't identify how or why they knew the gender. The training was basically hearing "yes" and "no" until you got it, but the trainees couldn't understand how they knew either.

I don't think there is much analog to programming on that one.

Sense memory and repetition. Give the non-linear parts of your brain a chance to get involved.

Job stuff question:

I'm very deep into interviews with 2 tech companies for non-dev positions. Interviewing with each this week and I'm pretty sure one of them is going to make a time-limited offer (word on the street is they only give you a day at best to accept).

I think I would be happy at both places, but one of them is a remote job, which I would prefer, and it's not the place that asks you to pull the trigger in a day. Is there any way to ask the remote job folk to speed up the process?

If I accept at the other place, I likely wouldn't start until the first week of next month or so. I know it would be ****ty to take a job and then back out if I get another offer, but would it be the end of the world, or just a badly burnt bridge?

TIA for any advice. I've never had a situation in my life where two companies were even vaguely interested in me and I have no clue how to deal with it.

Kerowo nailed it. It even directly references coding because I remember her discussing the lack of quality code for people to review over and over again and learn from to move past the mediocrity barrier (paraphrased terribly from the talk).



Sent from my SM-G900R4 using Tapatalk

If company A makes a time limited offer call whoever you've been talking to at company B and let them know about it. Either they'll counter or they'll say good luck. As far as taking a job you don't want while waiting for a better job it's a douche move but I don't know how much it will follow you around. If you want company B more than company A don't tell them it's a time based offer and see what they say.

1 day offer is a douche move in itself, so Id be incredibly wary and in general be okay with screwing them over for it. But I also understand if you need a job pretty bad.

Also would never hurt to ask for more time, even if you think its futile

I think its super douchey to accept a job and then bail right away if you get an offer you knew might be coming.

But I also think its super douchey to require responses to offers in something like a day (absent a few special circumstances).

So, meh.

I doubt it would hurt you long term - but there's always a chance you run into somebody at company you screwed down the road and they remember who you are.

@kero

I think I'd mostly be happy working at either place, but the time-limited offer place is probably my second choice.

I know the super limited offer is weird, but they are a smallish company with a very good reputation from current and former workers.

Definitely feel stressed to start working and getting experience, but I've also had an astoundingly high resume response rate since I started applying recently. Maybe I shouldn't be so frantic.