There are a few things that are worth thinking about. Or maybe it is just rambling.
FPGAs are not CPUsCPUs hold this state in RAM and legislatures, and change this state slowly, at best only a few words at a time. FPGAs can change a lot of state all the time if you let them. If you code for FPGAs as though they are CPUs, then you will miss the point of FPGAs
A design for an FPGA is static - for the most part you can't add more state information at 'runtime' - you do not have the FPGA equivalent of "malloc()" or "new" to add more logic. Instead try to think of your data flowing through your designs, much like how signals flow through a circuit.
Overthinking and OverdesigningFor the most part, FPGAs are just chips with inputs, outputs and clocks. Your job is to get the output pins to change as required by the inputs and the passage of time (as measured by the clocks). Your design does this by keeping track of information in a hidden, internal state vector, which evolves from cycle to cycle.
The simpler and more concise your description how this happens, the better the end result will be.
It is easy to overthink the problem, esp for a newbie. Ask yourself often "is this the simplest way to do this?".
As a general rule deeply nested HDL code with lots of IF statements is bad. If you do this, you are missing something about the problem and should see if you can decompose the problem more.
A simple design is easier to debug than a complex one.
Structure or behavioral codeLearn the distinction between structural and behavioral design. Your design is made up of little bits that behave in a specific way, connected together to make your design. Try to keep these aspects of your designs as separate as much as possible, at least while you are starting out.
Structural is like designing a schematic or PCB - how things are connected. Graphical tools work good at this, and this works well when using IP blocks, But HDL code isn't too good at this - it gets too verbose
Behavioral is like making the 'model' describing how an OpAmp works or other complex component works. This is somewhat hard to do graphically, but works well when using HDL code.
If you try to describe how things are connected and how they behave at the same time, it doesn't work well in either code or in graphical tools. Avoid this ugly middle ground!
Different FPGAs from different vendorsIf you ignore the more magical parts of an FPGA (e.g. PLLs), at the bottom of the heap are the FPGA's primitives. LUTs and FlipFlops, ALMs, Slices, whatever - these change between vendors and devices, but they are very simple and pretty generic.
You could build anything you want with enough four input LUTs and D-flipflops. It might not be most efficient, but you can do it. Likewise you can also build anything you like with a (impractically) wide enough RAM and an single address register (e.g. a 256x8 bit RAM can act as an 8-bit counter). For the most part, the different FPGA architectures have just decided to put a different stake in the ground along this continuum.
A design that is optimal for one FPGA architecture is usually pretty close to optimal for another - changing vendor or the part is not usually going to make your design much easier.
LoopsIf you write software for a while you have the power of unbounded loops fixed in your head. You need to retrain yourself to achieve your design goal without them.
This is like learning to write non-blocking code, but taking it to the next level. Don't try to be cunning and fight it or work around it - you can't win.
TimeTime for FPGA designs is very different for time in software or electronics. Everything happens all at once (in parallel), and then things happen so slowly (you can only do so much in one clock cycle).
Much like the shift to when you start shifting from DC to doing AC designs in electronics, or working in with maths in the frequency domain, or moving to writing real-time software you didn't know how much you didn't know what time really means until you finally get to grips with it. Once you do understand it, you can't see how it could really be any other way.