I suppose it varies a lot from one organization and industry to another. My experience is that managers don't like it when people rock the boat, they prefer their subordinates to just quietly execute the tasks given to them. Growth-oriented people like myself are sometimes seen as a problem because they cause things to happen that are not in the road map.
In my field (fin tech) managers often do not have the background to be able to assess the value of spontaneous technical contributions. So they assume that if something was not planned and requested by management it did not need to be solved.
> Growth-oriented people like myself are sometimes seen as a problem because they cause things to happen that are not in the road map.
Creating new work that wasn’t in the roadmap (excluding tech debt and other necessities to get roadmap work done) is a problem.
The right way to grow is to learn how to work with the company to get important work into the roadmap.
I’ve worked with some peers who had good ideas and good intentions, but they’d unintentionally try to blow up the roadmap and reset planning by prioritizing their work over the things we needed to get done.
Working with the business to get things prioritized is a necessary skill. A lot of engineers just want to work on whatever they want to work on most, but that’s a problem in the context of an organization trying to coordinate.
I am not talking about creating additional work, I am talking about solving problems not on management's radar screen. Some problems are only visible from the floor.
> The right way to grow is to learn how to work with the company to get important work into the roadmap.
That is not always possible because valuable things sometimes have to be demonstrated to be understood. Not all things can be explained in the abstract, sometimes you have to build the thing first before people understand how useful it is.
I agree with this sentiment. A good (software) engineer needs to have the discernment to know when to ask for permission, and when to ask for forgiveness.
A software engineer only needs to make those judgement calls in a bad environment. In a good environment, such situations can be discussed in the open.
It depends on the business. Many places have no idea wtf they want, and presented with something interesting they’ll ditch what they are doing to do it, because they don’t know why they are doing whatever they planned anyway.
The existence of this thread belies this. Running everything like a product is the fad today. It’s a fad because running a “product” means understanding its lifecycle and resourcing it as appropriate. But the mandate in BigCorp is to run printer ink fulfillment with the same methodology as an actual product, so lots of leadership time is spent thinking about toner or whatever.
It’s inefficiency created in the pursuit of efficiency via control.
It's not a problem, that's how you create software. You can put some of those initiatives on a "road map" if you want, but there must be space for them. 50% "slack time" is a good standard for software engineering. Your software engineers likely know better than your middle-managers how to spend that time.
You can't get important work into the roadmap while also complaining that people are trying to blow up the roadmap when they try to get important work into the roadmap.
Kind of a big problem here, as you're defining the right way as also the way that frustrates you (and assumingly others) the most.
> A lot of engineers just want to work on whatever they want to work on most, but that’s a problem in the context of an organization trying to coordinate.
May be it's actually a management challenge to turn this enthusiasm into money?
What's a problem for one person makes an opportunity for another person.
> My experience is that managers don't like it when people rock the boat
That's what's missing from Graydon's analysis: risk-aversion is also a strong incentive in many corporations. I would argue it's the rule for middle managers, with growth being the exception.
Also missing is telemetry and coordination, where companies use FOSS to find out what other companies are doing, or to coordinate policy, esp. when they fund a leading contributor from whom other companies need buy-in.
Put another way, a FOSS contributor is not an individual, they are a company representative, and their opinion has the weight proportional to the companies' influence.
The contributor's influence also depends on the composition of the other contributors. Alternate influences become impossible when a company dominates the contributors; hence e.g., the CNCF tracks metrics for ensuring that it takes a plurality to dominate.
But really this posting isn't about FOSS contribution at all; it's about the under-valuation of avoided future costs. But that's a much harder problem, because you get all sorts of illusory accounting when people project potential costs they're avoiding.
E.g., I um heard that at (big firm with ~1000 developers), the QA team was successful arguing for additional funding because they were finding more bugs. So the kernel team started tracking edits as fixing potential bugs, to restore the balance of funding. They hated the game, but had to play it.
The problem is they can’t justify your cost if you go outside the planned work load. They could probably still quantify it but it’s difficult to assess your impact when your effort doesn’t count towards velocity and delivery of business outcomes. If you work does impact those things, it should be a ticket/story/task so that the impact of work can be measured (seen…). I would suggest, in the future, adding these things to the backlog as you come up with them and bring them up during planning.
The measure is called an accepted pull request. You don't need a ticket to submit a patch to the Linux kernel. If you're in a dysfunctional agile micro-management environment with "stories" and "backlogs" then look for a real job.
Tokenizing everything in one go is usually the right approach. The typical case is the error-free case, so you won't actually tokenize more characters than necessary, but you will simplify the implementation and avoid jumping back and forth between parsing and tokenizing (thus improving locality).
"Codes" is correct when the intended meaning is access codes and the like, but not for source code, which is a non-countable noun.
I think the uptick is due to the increased number of participants who are not native speakers, mainly from Asia and eastern Europe I would presume--I'm not a native speaker either but the distinction between countables and non-countables is natural to me, coming from another Germanic language.
I'm surprised Figma is worth that much. For a while I was considering bootstrapping a business in this space and I was never very impressed with what I saw of Figma. Does not look that hard to compete with or replicate.
You'd never be able to compete because the design is the product. You'd just be stuck copying them, always one step behind.
Their interface's responsiveness is also a consequence of writing a rendering engine in WASM, so you'd have to figure that out too. [1] Plus the real-time collab. I don't know why you pretend as if these aren't difficult engineering problems to solve.
I found another product opportunity that will be faster and cheaper to build. That I believe I could out-compete Figma were I rich does not mean I _am_ rich.
Just my opinion, but your original comment comes off as comically dismissive of what Figma has done.
Adobe, a company with literal billions in cash and thousands of engineers, wagers 20 BILLION dollars that it is not easy to compete or replicate what Figma has done. In fact, they attempted to compete with Adobe XD and "lost".
The founders of Figma started working on the beginnings of it in 2012 (perhaps indirectly) and launched in 2016. They also raised 330+ million in VC money to make it happen.
I'm a bootstrapped at heart and love the idea of small companies outmaneuvering giant elephants but suggesting one could outdo Figma, with relative ease, just doesn't sound likely.
All that said, if you truly feel like you can, get out there and do it! Theres billions of dollars waiting for you.
I have never understood why (some) people want to write lexerless parsers. Lexing lets you approach two different concerns separately. What is not to like?
For haskell, I think a lot of it is just that parser combinators are _very_ satisfying and memorable. They're what made the whole Functor/Applicative/Monad thing really click for a lot of people as an interesting/useful thing beyond just IO.
Agreed, and I would state it more strongly: it's unclear how / significant extra work to provide good error messages if you have a separate lexer stage. And sooner or later you will want good error messages.
For simple languages, it can be a bit of a pain to write and maintain a lexer and a parser. For example, if I'm gonna parse JSON and nothing more, I think it's a bit silly to use a two external DSLs when I could use a simple eDSL. I think Happy and Alex both have their places, absolutely. For parsing full on programming languages I can imagine using parser combinators to be a bit painful. But parser combinators work great for a lot of cases.
You can still have a lexing step when using a parsing combinator approach, and in practice you probably should for complex parsing tasks. Unfortunately, I'm not sure I've ever read a tutorial which really walks through doing such a thing.
Most Sámi are not reindeer herders, and thus are no more nomadic than your average Norwegian. Even going back hundreds of years, many Sámi were primarily fishermen and didn't travel much.
I am not sure what you mean about static fences? Reindeer is semi-wild. They gather them for sure (with helicopters and stuff these days), but outside that the reindeers basically go anywhere they want. Yes, they have ”areas” where they should be, but they are, as mentioned semi-wild animals. I have cottage in Lapland and it is very common to see them on my property almost daily. I like it, but I understand locals do not like it that much, as basically they eat everything you want to grow for yourself (and at north, it is already hard to grow anything).
In my field (fin tech) managers often do not have the background to be able to assess the value of spontaneous technical contributions. So they assume that if something was not planned and requested by management it did not need to be solved.