> . We seem to do stuff that's out of the normal experience (Python to create thousands of individual reports on thousands of rows of postgres data per report)
Sounds like you need somebody that knows Python and SQL, should be easy to find. Everybody thats been in the business for a while has done reports. However everybody also hates doing reports, so you might have to pay more than you want to, or hire interns to do it.
> A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly
I would just look for somebody experienced then, maybe 3 years +. Its going to cost more though, especially if the codebase is ugly and most of the work is reports.
> I've been largely responsible for hiring developers (usually on contract)
Hiring on contract is unlikely to get you desirable hires. Good devs have a lot of options.
My somewhat generic advice is to have a coding assignment. Some people won't do them but its the best way I've found to screen candidate quality. Equally important is to have a good developer look at the submissions. The quality of code as rated by good devs has always correlated strongly with the quality produced once hired, at least from what I've seen.
Advice for your situation specifically is to offer a lot of money and don't do contract-to-hire. Reports suck, your codebase sucks. Good developers can find another job within weeks and won't stick around unless you make it worthwhile. Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already.
You can nab good people for a lucklustere job without paying a premium if you're willing to give rare concessions. Fully remote work, flexible hours, part time, 4 day schedule, relative autonomy, etc. If you can't do that or pay well turnover will remain high.
You're not in a good spot right now. If you're open and honest about the job "writing reports in a crappy codebase" you won't get many interested hires and those you find will ask for more money. If you lie/deflect you will hire more but turnover will be insane. Your best option may be to hire interns. They will expect the job/code to suck and ask for little money. Turnover will remain high and quality will be all over the place, but at least it will be cheap.
>Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already
That seems like an odd thing to say. Where do you jump from "undesirable" to "low quality"? Isn't it exactly the undesirable but fair quality people who are stuck doing contract to hire? That is, those who are undervalued in the marketplace? It seems like a doubtful plan to insist on only chasing people who don't need the position you want to fill and probably don't want to do it.
I heard lack of effective management structure was a far worse consequence of Valve's unusual structure. Heard influence became based on connections and favors, not good results or ideas. Heard many good projects died, even ones that would make sense to a third grader (HL3 L4D3). Hearsay but its all over internet if you're curious
Part of me will never fully forgive them for just letting Half-Life 2: Episode 3 die, never officially cancelling it (even to this day), and refusing to communicate with their fans about it.
People meme about HL3, but most of us Half-Life fans just wanted Episode 3. Episode 2 ends on the most heartbreaking cliffhanger, and we just wanted some sort of conclusion to that story.
From my estimations they could not release Episode 3 as public hype eclipsed anything any game studio could produce. The anticipation became too strong as people expect nothing less than perfection. They used Alyx to re-anchor expectations
Edit: I believe a similar phenomenon occurred with Disney's Star Wars Sequel Trilogy, objectively some mistakes were made, but the sheer outcry from fans is an order of magnitude stronger than the mistakes made, imo this is caused from the mismatch of the idea of what Star Wars can be/means to you versus what you can concretely produce (with technical and cultural constraints)
Could you share a few spoiler-free thoughts about HL:A as a dedicated series fan?
I'm in the same boat. Loved HL1, then HL2 even more, it's one of the very rare games I regard as perfect. Then both Episode 1 and Episode 2 surpassed my expectations, and I was very disappointed with Valve's refusal to say anything at all for years. The HL:A announcement took me by surprise, as I had given up on more HL.
Do you find HL:A to be a good Half-Life game first and foremost? Do you feel it has the top-notch environmental storytelling and attention to detail that the series is known for? Does it make good use of VR's potential?
I'm considering upgrading my PC this year, largely for HL:A and Cyberpunk 2077. The last time I tried VR was with the Oculus Rift in 2016, and it felt underwhelming to me. Very cool for an evening, but then the novelty wore off and the actual gaming felt less satisfying than traditional non-VR.
Of the handful of games I've played in VR, Alyx by far feels the most like I am physically present and able to interact with the world. The one time I've ever been tricked by the illusion was when I bent down to look under furniture in a room, and then I tried to push on said furniture to help me stand back up, oops.
Like other Half-Life games it has great physics. You can pick up a marker and write on a pane of glass; you can shake a bottle and see the liquid inside slosh around. The gravity gun concept returns and it is as much fun in VR as when you first picked it up in HL2.
I won't go too much into VR-centric game mechanics for spoiler reasons, but I'm impressed with how creative they got with hand tracking. As one example, reloading is combat is tense because I have to actually go through the motions of getting out a new clip, ejecting the spent one, chambering a round, etc. while a zombie lumbers toward me.
The other comment did a great job of explaining HL:A specifically, but I'll answer a few other parts of your comment.
> Do you find HL:A to be a good Half-Life game first and foremost
Absolutely, it's raw HL. The game itself is in the 12 hour range, which is very much in the HL1/HL2 range. It does feel a bit shorter (narratively), but it still is full of content switching between puzzles, combat and story telling.
> Do you feel it has the top-notch environmental storytelling and attention to detail that the series is known for?
Absolutely. It is a bit different, since this is a VR game, but if anything I would say it's even stronger here. The focus is different to fit the controls, but there are truly "WOW" moments. I still remember having my mind blown in HL2 when the huge tower falls as you ride the boat. This game similarly amazes, but in an even more immersive way.
> The last time I tried VR was with the Oculus Rift in 2016, and it felt underwhelming to me
As someone who has had the original Oculus prototype, then the HTC Vive, then the Valve Index. I will say that each iteration made an order of magnitude difference in almost every metric: immersion, comfort, motion sickness, etc. With the latest setup, I would easily spend 3-4 hours straight in Alyx, until the point where my legs started hurting (before my face/stomach, which was the case before).
> I regard as perfect
Unfortunately, I think this is why it ultimately took them so long. It was truly hard to follow up all those great games, and they wanted something they could really be happy with. HL:A does mostly deliver that, though partly sidestep the issue by switching to a different medium, where the standards of a perfect game have not yet been created.
At the end of the day, it does very much feel like a HL game, to a veteran who has played their games over and over.
> Do you find HL:A to be a good Half-Life game first and foremost? Do you feel it has the top-notch environmental storytelling and attention to detail that the series is known for? Does it make good use of VR's potential?
Yes, 100%. It's the best VR game I've played and I own ~30. Its the only VR game I've played for more than ~1.5 hours straight (I finished Alyx in 2 4 hour sessions and 1 3 hour session).
It's not a novelty. There's segments in the game (particularly at the end) that are incredibly engrossing as a result of VR.
I've been playing it as well, but I'm not too far in. It hasn't grabbed me much yet. Part of that might just be that 2020 has me in a bad headspace, so it's hard to enjoy things as much.
They are the sellers of a VR headset, and want to increase the odds of that market taking off by adding a great game to it. Business decision wasn’t based around the game’s ability to sell well, but it’s ability to sell headsets. While this one game isn’t going to get me to buy a Vr headset, enough games at this level could, and there 100% are people who bought the headset just to play Alyx.
Which isn’t to say that Alyx could have been made as a non-VR game, from what I know VR is completely integral to the experience. But in choosing to make a different game that could have sold gangbusters vs making this game to support their hardware, they chose the latter.
Edit: Oh also they are so loaded they can do whatever they want basically and as a private company have no authority to answer to that can force them to pursue profit. I get the feeling Gaben is entirely happy with his current level of ludicrous net worth and values seeing a big change in the landscape of gaming in his lifetime over making more money. (It’s also possible that attempting to make new markets for Valve to take a 30% cut of is the best long term strategy to make money regardless)
I had thought the same, until I actually played it, and then it made complete sense. It's hard to express how difficult it would have been to have designed a non-VR counterpart with it until you're in the game experiencing it -- the pacing, the environments, the Combine, etc. I feel it's completely different than any Half-Life game, or FPS game that I've played, but familiar at the same time.
As far why they did a VR game at all: I suppose they like to test the waters.
This is my own analysis, as a Valve veteran for 20 years and someone who has followed every twist and turns. People will say they made this game to sell VR headsets, but from my vantage point, it's the opposite. They actually created VR mostly for Half-Life.
In one part, HL games were always a place for innovation and pushing the gaming boundary forward. It may have just been fun games to you, but HL1 defined storytelling in FPS games, and HL2 defined physics puzzles and grand landscapes. Each game was better than the previous and eventually they got stuck no being able to make something they were truly happy with.
Valve has always been more satisfied creating something new than more of the same. They experimented with a lot in the past decade. They tried making a horror game with biometric sensors, which did not work but lead to the Steam Controller. They tried a lot more things but VR finally fit the bit. It allowed them to partly sidestep the "perfect game" issue, by switching into a new area that wasn't yet explored and allowed for innovation again.
So yes, they made a VR game because they are once again able to push gaming forward and create a truly unique game, which is the only way they will be satisfied enough to release a game.
People talk a lot of shit about Valve without having a clue, a consequence of their secrecy and their position as a premier game developer. I wouldn't trust anything that is said about Valve that didn't come from someone who has worked there.
Tyler McVicker/Valve "News" Network is a major component of this. His interviews with Valve are great. His speculation is trash.
1. Steam became a success because of the games Valve developed.
2. Epic created Fortnite, which you likely know is a popular release. That game is leading to the Epic store getting off the ground and gaining traction. This is causing a rather large loss in revenue for Valve.
That's why games are important. If you control the top games, you control the users, and you control the platform.
Epic Store is light years behind Steam. It is very barebones and primitive. In Steam when you go to the games in your library you see a lot of content, you see your DLCS, achievements, community content, etc. In Epic Store you don't even have a page for each game in your library, just a small cover to launch the game. Steam has Play on TV, Play on phone/table and Remote Play together which are great features. Also Epic catalog is so much smaller than Steam's.
Also, it is interesting to have some context of Epic Games.
I remember when it was Epic MegaGames and they released the original Unreal games, THAT was the hit that defined the company as they also started to license their Unreal Engine (which they still do today).
Long story short, around 2012 the massive chinese giant Tencent acquired a big portion of Epic Games (40%) that allows Tencent to nominate directors, and the company shifted towards GaaS (Game as a Service). Many long time Epic Game employees left the company around that time.
Epic Games used one of their games, Fortnite: Save the World, to develop Fortnite Battle Royale, which was a huge success.
It's very important to note that Fortnite's biggest competitor, PlayerUnkown's Battlegrounds (PUBG), is owned and developed by Tencent.
Also note that Tencent owns 100% of Riot Games, as well as having various stakes at different gaming studios.
All no doubt very good points, but they also don't meaningfully matter. The cold fact is that Epic is doing way better than most people want it to, regardless of how bad it is or how shady it's investors are.
Eh, you only need strong games to get your platform started. As you pointed out, HL/CS helped really kick starts Steam, and similarly Fortnite helped kickstarts Epic. But once your store picks up, I don't think game exclusives are as necessary as you imply to keep it going. Do you think all Steam games are just going to leave if Valve never makes a game ever again?
> Steam became a success because of the games Valve developed.
So what? That was years ago, and that says nothing about the present state of affairs.
> This is causing a rather large loss in revenue for Valve.
No it isn't, because you are missing the fact that the gaming market is not a zero-sum game, fix-cake that you can only get a share of. It's constantly growing, and new games create new public the whole time.
> So what? That was years ago, and that says nothing about the present state of affairs.
You overlooked my second point, about Fortnite leading to the Epic store gaining traction, which is the present state of affairs. Also look at EA Games launches their store in the past by using their AAA games as leverage. All these gaming stores and trying to use games as a way to get their foot in the door, so I think you're wrong by saying it's no longer a valid approach. In fact, it's the only approach that seems to work.
> No it isn't, because you are missing the fact that the gaming market is not a zero-sum game, fix-cake that you can only get a share of. It's constantly growing, and new games create new public the whole time.
It's very much a zero-sum situation when these stores sell the majority of the same games. When you spend your $60 buying Grand Theft Auto on the Epic store, that's a $60 loss for Steam, because you're not going to buy the game twice. When one store wins your sale, the other loses it.
So let's say you make 10 bazillions dollars per day just by running your store, and releasing a new game that takes a lot of efforts and 3 years of work would only result in 0.001 bazillion dollar in 3 years of sales, does it make sense to sweat making games anymore? The maths speak for themselves.
Let's say you make 10 bazillion dollars per day running your store, then you pay someone else 0.0001 bazillion dollars to make 0.001 bazillion dollars in 3 years.
No, it's worse at flat management companies like Valve. Since you don't have anyone in charge, and everybody works on what they want, there is no objective measure of whether or not you're doing well. Everything comes down to politics, from bonuses, to who gets laid off during downsizing, being very good at your job isn't enough. That's how it's been at the flat management company I worked at, and how it seems everyone who's worked at one describes it.
Yeah, I think the complaint was that Valve is/was theoretically flat, in that people could self-manage, but in practice, it had an implicit hierarchy that was obscured by the officially "flat" structure (which, let's be honest, was always kind of a lie, because I guarantee you there's someone there who can fire other people, which means it's not actually flat). And an implicit hierarchy means that there's no way to say "I had these goals and objectively achieved them"; you aren't making your case to a defined supervisor, you're making a case to the informal supervisor. That'll almost always wind up with favoritism without any potential escape.
Some of these problems exist in any company, but at least in a standard hierarchy, if your boss is sabotaging you or ignoring you, there are routes you can take (go to their boss, go to HR) to (imperfectly) route around that. In a flat structure, you're grasping at ghosts - after all, no one's your manager, so it shouldn't matter if one person has it out for you, but of course, if they're politically entrenched, it absolutely does matter. And there's no one in the company to complain to, because the company's official position is "this is impossible, we're a flat company", and your complaints are minimized if you complain externally, through some combination of "sour grapes" + "but it's a flat system!".
Honestly, it's a great trick on management's part - everybody has the responsibilities of management, but no one is an official manager, and there's an easy playbook to run on anyone who complains.
Any "objective measure" that a regular company uses is mostly a way for management to pose and bluster about what they actually want. Corporations are fundamentally all the same.
We have found H2 in Postgres mode to be the fastest way to test db stuff, at least in Postgres and Java. In Go you might lose most of the speed advantage since its not running "in JVM". It also doesn't support many of pg's advanced features
I'm generally not a fan of emulating database behavior through a mocking layer while testing/implementing. Even minor version changes of PostgreSQL plus it's extensions (e.g. PostGIS) may introduce slight differences, e.g. how indices are used, function deprecations, query planner, etc. . It might not even be an erroneous result, just performance regressions or slight sorting differences in the returned query result.
We try to approximate local/test and live as close as possible, therefore using the same database, with the same extensions in their exact same version is a hard requirement for us while implementing/testing locally.
However, I have no experience with H2 (and the modern Java ecosystem in general), so cannot talk about how close their emulation implementation resembles PostgreSQL behavior.
I'm a Java developer, but I take issue with your last point:
"Single binaries are overrated. Any app that's widely distributed uses an installer [...]"
That's true once you have the kind of traction where distro maintainers are going to consider packaging it themselves. But to attain that kind of popularity having a stand-alone binary is going to make a huge difference.
Unless you're willing to build all those packages/installers from scratch!
My opinion is between these. A single binary is easier, and the java app deployment could be made better than it is now.
Currently I make an 'uberjar' that includes all java dependencies including Tomcat/Jetty/etc: java -jar my-app.jar
What's annoying is finding the desired JDK/JRE for each OS with the right license and manually installing it. Sometimes having to make some file fixes (e.g. OpenJ9 JDK & Maven compatibility).
Another benefit of using the JVM is that you have a variety of languages to pick from that target the JVM and can interop with Java, which means you gain the benefits of all the libraries but also being able to experiment with other languages.
> There would be no A bomb without this, for example, nor US moon missions.
These were mostly German weapons scientists brought to the US near the end of WWII. The alternative was being sent to Russia. Russia was brutal to PoW's so given the chance everybody tried to surrender to US and European troops. Not really regular brain drain that time.
Brain drain always happens from poor to rich countries. Those able to move to greener pastures will, I don't blame them. This is even happening within the US in Illinois. High taxes and precarious government have led to massive migration away from the state. Highest percent of college students going out of state, and average person moving to Illinois makes nearly $25,000 less than average person leaving.
You can't blame people from wanting a better life for their family. In the end it does concentrate wealth, but maybe it will eventually just concentrate the population? This seems to be happening in China, with massive migration to megacities. Rich or poor, the countryside is being abandoned, so there's not many being hurt by the migration, just empty buildings
> I seriously doubt this was ever an existential in the sense of the shipping cost itself destroying a business.
I've read many e-commerce blogs with US sellers lamenting that they can't compete with China on $5 items because shipping costs are 5X as much within US. Maybe not killing businesses, but definitely keeping many out of the market.
> China is simply able to produce cheaper things because they have lower labour cost and so on, and that is actually good for American consumers
Lower, but not nearly as low as it used to be. Minimum wage in China is almost 1/2 of US now.
There's real instances of shipping cost offsetting lower labor. Manhole covers are a somewhat famous example. They're still made in USA because shipping offsets increased labor and materials. Would it be the same for ecommerce? I'm not aware of any studies but to me, the increased cost and shipping time make it plausible
Its not just a Rust problem, I've run into the same thing in Java and I'm sure it exists elsewhere. The only answer I can come up with is to keep your app cleanly divided into modules. There's some cognitive overhead but its usually worthwhile.
I recently divided a 100k line Java app into 5 different modules and it compiles 4 times faster. The new boundaries have encouraged better code as well. Suddenly we have things like interfaces and IoC. Before, people just stuffed things wherever.
Definitely not the same. With Java, you decide what you want to compile with your build script. You don't need to compile entire application as a single unit. If you have to recompile a lot of code when you only make small modification it is likely because did not use many of available ways to just recompile the classes that you modified.
Also, with Java some optimizations are pushed to runtime. JIT has access to all code running even if it wasn't available at compilation time.
Conspiracy, but I don't think the US ever stopped researching nuclear propulsion. There's too many advantages. They built a few working and miniaturized test engines in the 60's but never put them on planes? I don't believe that. They put nuclear weapons on planes all the time and thats not much safer. More likely, they never told anybody they put them on planes, for obvious radioactive reasons.
An aside, the strange craft reported recently with the famous jet fighter videos had "impossible performance" and were all filmed over the ocean. The ocean would be the only safe place to test nuclear drones. And their performance would be quite unmatched by anything else. The pilots even reported that they submerged, sounds like a great failsafe if your super secret black project gets seen. I doubt you would submerge a jet turbine, but nuclear propulsion could easily work under water
I can't find it, but I saw a comment on HN back in April I believe (when the Pentagon released videos of UFOs) explaining exactly your theory with some interesting sources.
Very true. IMO many people that hate XML config files just haven't used an IDE that validates schema. Its super nice to have auto-complete and property validation on config files, something not offered by JSON or YAML. A good reason to stick with XML for complicated configs.
Its one of reasons I don't mind maven. Yeah there's 1000+ line XML config file, but maven DTD is so tight nearly any syntax issue will be flagged. Something easy to appreciate when you're used to giant config files that don't get validated until runtime.
Visual studio does schema validation for JSON and gives errors inline. There is a big list of supported schemas built in and you can define your own. Never actually looked at the format personally.
While I generally agree, I'm not sure maven's pom.xml (aka porn.xml), of all things, is a paragon of good markup design ;) For one, maven actively forbids/rejects use of ordinary XML entity references, and invents its own text expansion instead (so strictly speaking pom.xml isn't even XML proper). Then using XML for a relatively simple EAV format seems like overkill. But yeah, over a decade ago the maven developers had great plans to open up the format for alternative serializations/DSLs; thankfully they didn't, if only because they realized it isn't worth the maintenance effort. I'll add that a format for describing software builds is probably the wrong place to let a thousand blossoms bloom, something that you realize soon enough if you've worked as freelancer in Java-ish project's for any amount of time, and where every other project is feeling the urge to use the oh-so-great gradle as an alternative to pom.xml.
My comment was only aimed at service payload serialization; as to whether markup makes for a good config file format, I'm not entirely sure. It certainly is better than inventing an ad-hoc format IMO, but OTOH there are a couple of not-quite-SGML/XML config formats such as Apache's httpd.conf, or in fact maven's that just give XML/SGML a bad name IMHO, because they generally inherit the downsides of markup without bringing its benefits (such as being able to assemble a configuration from fragments using regular entity expansion).
Very Java-esque name for the largest Java project there is. I like it.
"Eclipse AdoptOpenJDK Adoptium" has a good ring to it. Reminds me of the SharedSessionContractImplementor I worked on last week for our Hibernate interface.
Sounds like you need somebody that knows Python and SQL, should be easy to find. Everybody thats been in the business for a while has done reports. However everybody also hates doing reports, so you might have to pay more than you want to, or hire interns to do it.
> A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly
I would just look for somebody experienced then, maybe 3 years +. Its going to cost more though, especially if the codebase is ugly and most of the work is reports.
> I've been largely responsible for hiring developers (usually on contract)
Hiring on contract is unlikely to get you desirable hires. Good devs have a lot of options.
My somewhat generic advice is to have a coding assignment. Some people won't do them but its the best way I've found to screen candidate quality. Equally important is to have a good developer look at the submissions. The quality of code as rated by good devs has always correlated strongly with the quality produced once hired, at least from what I've seen.
Advice for your situation specifically is to offer a lot of money and don't do contract-to-hire. Reports suck, your codebase sucks. Good developers can find another job within weeks and won't stick around unless you make it worthwhile. Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already.
You can nab good people for a lucklustere job without paying a premium if you're willing to give rare concessions. Fully remote work, flexible hours, part time, 4 day schedule, relative autonomy, etc. If you can't do that or pay well turnover will remain high.
You're not in a good spot right now. If you're open and honest about the job "writing reports in a crappy codebase" you won't get many interested hires and those you find will ask for more money. If you lie/deflect you will hire more but turnover will be insane. Your best option may be to hire interns. They will expect the job/code to suck and ask for little money. Turnover will remain high and quality will be all over the place, but at least it will be cheap.